Hi Steve, Quoting [Fisher, SM (Steve)] (Jan 25 2008):
-----Original Message-----
Hi Steve,
here are my belated comments:
#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 '%'"?).
I can see the attraction of your proposal - the only problem is that it elsewhere if you specify no filter then everything is accepted, here you you are giving a special meaning to the empty string. This then means that you have to specify VO with a wildcard as you have suggested - i.e. "VO LIKE '%'" I would quite like to hear the opinions of others on this.
Yes, me to. silence so far :-/ I agree with your point, tough call. Anyway, I included a different proposal in the tex sources, which also addresses a different problem, that of non-standardized 'type' values. It reads: Some examples are: \begin{itemize} \item |type = 'org.glite.security.voms'| \item |site IN ('INFN-CNAF', 'RAL-LCG2')| \item |type = 'ResourceBroker' AND Site LIKE '%INFN%'| \end{itemize} % AM: I really see problems with the non-standardized type values, as % that severely limits the usability for other SAGA classes. Assume I % want to discover an URL I can use for the creation of a % saga::job::service instance: what type do I look for? % % Proposal: allow special type=saga::job::service, and return only % URLs which can then be used for constructin that instance, in this % session (that also solves the VO/context problem I mentioned % earlier). The implementation needs to (or needs to try to) % translate that into meaningful types. Well, better the translation % has that job than the end user! Would love to hear your opinion on that. Either way, I very much would like to find ways to more tightly integrate the SD package with the core API...
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?
Please go ahead - I will see what you do!
Well, what do you make of it? :-) I hope I did not mess up anything... Cheers, Andre.
Steve
-- "We've got too much time to waste to stand around here doing things." - Tigger