[SAGA-RG] SAGA SD Final?? Version

[Fisher, SM (Steve)]

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.

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

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