[SAGA-RG] SAGA SD Final?? Version

[Andre Merzky]

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