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