[SAGA-RG] One final thing to agree upon for SD

[Sylvain Reynaud]

Steve Fisher a écrit :
> 2008/10/22 Andre Merzky <andre at 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.