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