Hi Steve, here are my belated comments: Quoting [Fisher, SM (Steve)] (Jan 02 2008):
From: "Fisher, SM (Steve)" <S.M.Fisher@rl.ac.uk> To: SAGA RG <saga-rg@ogf.org> Subject: [SAGA-RG] SAGA SD Final?? Version
Hi,
We have made the following changes to the Service Discovery spec:
#1 Section 2.1.1: now includes reference to GLUE
perfect.
#2 Should the default VOs be chosen from the session object?
As we are not able to come up with an intuitive syntax that allows the user to be able to request specific VOs or to take one from the security context we prefer to leave this as it is.
I was somewhat unclear here I guess, as you would need no additional syntax, but only additional semantics: // pseudocode! saga::context c ('X509'); c.set_attribute ('UserVO', 'O=dutchgrid'); // create a saga session which uses that context saga::session s; s.add_context (c); // create a service discoverer in that session saga::service::discoverer sd (s); // when searching for services, and when no VO filter is // specified, we imply an VO filter from the session // contexts sd.discover ("Type = 'Broker' AND name = 'CERN-PROD-rb'", "", "RunningJobs > 10"); // this is thus actually the same as: sd.discover ("Type = 'Broker' AND name = 'CERN-PROD-rb'", "VO IN ('O=Dutchgrid')", "RunningJobs > 10"); The syntax is the same as before, but semantically, the empty VO filter is interpreted differently. Does that make sense? It would free the user from the need to explicitely filter for VOs. In fact, as the session is defined to pick up default credentials, the user would not need to know anything about VOs at all, and still receive only services which are actually usable for his credentials. That should nicely fit to the 'S' in SAGA ;-) OTOH, one can revert to the old semantics with the VO filter 'VO=*' (I guess? Or is is "VO LIKE '%'"?).
#3 When there is Authz failure, should list_services throw 'NotEnoughPermission' exception?
We have added the AuthorizationFailed exception
(Incidentally I don't like the distinction between PermissionDenied and AuthorizationFailed in the core specification. I see no adequate justification for it - Steve)
The spec says: 'The differences between AuthorizationFailed and PermissionDenied are, admit- tedly, subtle. Our intention for introducing both exceptions was to allow to dis- tinguish between administrative authorization failures (on VO and DN level), and backend related authorization failures (which can often be resolved on user level).' Yes, we know its a weak distinction, and slightly arbitrary - OTOH, it may provide a help to the end user, and give him a hint when to contact an admin. That is an often occuring problem in all projects I was involved in, that users get all types of security errors, and never know when they can fix it (or not).
#4 To mention compliance to upcoming GLUE stds. (GLUE 2?). Whether GLUE upgrades affect the document? if so, appropriate mentioning required. (comments: similar to SAGA-core spec depending on JSDL)
A footnote has been added
The examples have also been updated to correspond precisely to our implementation.
Note that we do now have a complete C++ implementation with gLite adapaters. The main code will be checked in as soon as Paventhan has write access to the repositoy and the adapter code will go into the gLite repository.
We would like to see the document go to the OGF editor now unless somebody sees a problem. The .dvi file is attached.
I have a couple of minor suggestions for the text, mostly clarifying sentences I had difficulties to parse. Do you want me to send it by mail, or would it be ok to change in CVS directly? Cheers, Andre.
Steve and Paventhan -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.