Steve Fisher a écrit :
2008/10/22 Andre Merzky <andre@merzky.net>:
[...]
I also think that the results of the discover() call should, first of all, be usable within a specific saga session. As limited as a saga session object might be - discovering services which do not (easily) map to a session context will not be very useful to a SAGA programmer, IMHO.
This requirement is already satisfied because if you omit the "VO-filter" the information is taken from your context. The implementation of the API could select using any group or role information without it being visible in the interface
In order to fully satisfy this requirement, a sentence on page 11 needs to be modified : << If it is omitted the VO filtering is performed on the VOs of the contexts in the session. >> For example: << If it is omitted the authorization filtering is performed on the attributes of the contexts in the session. >>
[...] I think the main question is whether or not we should allow selection on authz info and whether or not we should even allow this information to be queried on a returned service. I can only think of 2 reasons to keep it. The first is to make the API useful to someone without a security context and the second is for an application wanting to collect information and make it available on a web page - i.e. republishing the information. Both of these are more relevant to other middleware components than to end users. I will ask a few gLite people to get their opinion.
What do you think?
I think the use-cases for 'vo_filter' are not part of the 80% use-cases of the "80:20 rule". Moreover, 'vo_filter' is not consistent with what can be expressed in a SAGA session, and adding new key-value pairs to make it consistent would lead to an API too complex as you said it in the first mail of this thread. Because of this, I am in favour of the removal of 'vo_filter' from the specification. Cheers, Sylvain.