[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