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

Hi Steve, Quoting [Fisher, SM (Steve)] (Feb 15 2008):

Andre,

Sorry for the long delay. My excuse this week was that I was at the EGEE User Forum talking about SAGA and service discovery - among other things.

:-))

...

% 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?

I can see the need for some predefined SAGA service types then it can be used to find SAGA services with well known types and non-SAGA services as well. On a practical point how do we define the set of defined saga service types? Each time a new service comes along do we have to update the SD spec to include it? If we do it the other way around then the core spec has a dependency upon SD which is just an add-on.

Easy: define the type to be the string saga::<package>::<class> with <package> and <class> being the literal names as defined in the respective language bindings. That way, the SD package grows with upcoming extension packages... Thus we come to saga::job::service saga::rpc::rpc etc. withou the need for defining these strings explicitely.

...

% 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!

I don't like the side effect that you propose. To provide the functionality of getting the VOs from the available contexts I would prefer to add a call such as: list_services_in_session which will have no VO filter.

However even this is potentially confusing. If you use the system without credentials you will find no services - even though the information on available services is world readable

I appreciate that the S is meant to be simple - however I think that easily described behaviour is an important aspect of simplicity.

Yes, its a tradeoff between simple definition/concept and simple usage, I acknowledge that. I appreciate your concerns about side effects. Having semantics which is not intuitively expected from the user, and potentially differes from call to call, can be a source of great confusion. My concern however remains: w/o some way to express that only usable (in the current application) services are to be returned, the default use case is getting difficult: the user has to either extract the VOs from the session manually, and to create the VO query, or she has to filter the returned URLs for valid ones (I am not sure how that can actually be done, apart from trial/error). Well, I _assume_ that this is the default use case, but I really think it is what most people are going to do with SD in SAGA. Your proposal to have an extra call for that semantics is nice - sure, that clutters the API, but avoids side effects and complex semantics. discover_in_session () may be a better name (more similar to the original discover), but well, naming... :-P As for using the system w/o credentials: well, then you cannot use the system anyway, so that does not change anything. Also, the default session MUST always pickup the default credentials, which should always be good enough for local bindings (if the implementation provides any). So I think that behaviour is just consistent, and actually better than getting zillions of services returned, none of which can finally be used...

Only some contexts can be expected to support VOs, so for now I propose to leave the spec as it is and in a later version of the spec add an extra call that takes VOs from the set of contexts in the session.

Incidentally the SAGA spec only has one UserVO per context. Using VOMS you get multiples Vos.

Thats an interesting point, and seems to be a shortcoming of the context class then. The VO should be a vector attrib then I guess. I will add that to the errata. I am happy with all the other comments, thanks! Cheers, Andre.

Concerning your comment about lines 187-193 in the source file. I agree I have got it wrong it should read:

"Each of the filter strings uses SQL92 syntax as if it were part of a |WHERE| clause acting to select from a single table that includes columns as described below for thst filter type. If the programming language permits it, empty strings may be replaced by a representatation of NULL. SQL92 has been chosen because it is widely known and has the desired expressive power."

You also ask what happens if the query referecnes columns that do not exist. This is explained on page 11 - BadParameter is thrown. However in the case of the data filter no check can be made except on syntax.

The use of 3 filter strings simplifies the specification and potentailly the implementation as it makes it impossible to specify constraints that relate for example VO and service type.

Steve

-- "We've got too much time to waste to stand around here doing things." - Tigger