[SAGA-RG] SAGA SD Final?? Version

Andre Merzky andre at merzky.net
Sun Feb 10 15:40:32 CST 2008


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


More information about the saga-rg mailing list