[SAGA-RG] Service Discovery spec updated at last ...

[Andre Merzky]

Quoting [Steve Fisher] (Dec 17 2008):
> >
> >> >  - separated suggested SAGA service names for files and
> >> >    directories (a file URL cannot be used for a dir, and
> >> >    vice versa)
> >>
> >> I don't agree with this - it used to be your way round and it was
> >> criticised by one of our reviewers. You don't generally want to access
> >> directories and files by different services unless the underlying
> >> system used a  universal naming schema such as AFS.   However,
> >> checking the main spec again, I see you have no way of controlling
> >> which file/directory service you use - it is under the control of the
> >> implementation.
> >
> > Well, the service is (explicitely or implicitely) specified
> > by the URL you use to open the file/dir instance, like
> > 'ftp://ftp.redhat.com/' points to a very specific ftp
> > server/service.
> 
> Your example clarifies this - thanks
> 
> >> So at least file, directory, logical-file and
> >> logical-directory should be removed from this table until
> >> such time as they provide a means of selecting the service
> >> to use.
> >
> > Would it be ok for you if we remove 'file' then, and limit
> > to 'dir'?  Usually, one would like to discover services for
> > whole file systems, not for individual files, I presume?
> 
> Yes I think what you want to discover is a file service - and that
> this file service will offer both file and directory operations. 

Yes.


> I
> guess the same is true for the logical file service. If this is the
> case the table was fine as I had it!

Yes, from service perspective it was, I agree.  

The problem is that the end user simply has no means to know
what to do  with the returned Service URLs: are they usable
to create a directory instance _or_ are they usable to
cerate a file instance?  It can't be both, and, apart from
guessing or trying, the user has no good means to distingish
these cases.  

That is why I suggested to query for the two types
individually, but, taking you arguments, and Sylvain's,  I
think its ok to limit ourself to directories (I assume that
would usually be the root directory served by the service).

See new version attached.  Sorry if I am repetetive, just
trying to be clear...


> >> A few lines later you have changed related service to the plural -
> >> please change it back. Only one value is permitted.
> >
> > I am confused: we are talking about:
> >
> >  "_related_services_ the uids of a services related to the
> >    one being looked for"
> >
> > ?  Related Services are explicitely listed in plural
> > everywhere else in the document:
> >
> >  - figure 1 shows a n:n relation
> >  - the related_services attribute is a vector attrib, and
> >   the description talks about a list of uid's
> >  - get_related_services returns a list of related services,
> >   too.
> >
> > So why is it a single value during query?
> 
> because you say "related_service = 'fred'" or "related_service in
> ('fred', 'bill')" where it will always be used naturally in the
> singular. This assumes that 'fred' and 'bill' are actually service
> uids.

Thanks, got it.


> > What is a difference between an empty URL and an optional
> > one?  I don't think I can think of any case where an empty
> > URL would have a different meaning (like you motivated for
> > the empty authz filter versus no authz filter).
> >
> > Again, I would be happy we could keep that consistent over
> > the API and extensions.
> 
> I would like to be consistent - however the url here is not a string
> but a SAGA URL object - so it cannot have a default value of "".

Basically, it means that the URL would be created by giving
an empty string to the URL's constructor.  

Thus

  object (saga::url u = "");

is a short form for

  object (saga::url u = saga::url (""));

  

> Whatever syntax is appropriate for an optional session parameter is
> also good for an optional url parameter.

Well, we describe the session parameter default explicitely
in section 3.5.2 in the Core spec, but we do not describe it
for other parameter types anywhere, in particular not for
URL.


> In a python API I would then expect to see named parameters with
> defaults of None and in Java I would expect the constructor to accept
> actual parameters of null objects.

Sure sure, but that is a language binding issue.  You see
the same for the current Python bindings for the core
classes IIRC.  

Again, I think you are not adding any new semantics by the
second constructor...


> >> In a similar manner I don't like having the list_services call
> >> repeated (with and without the optional parameter) as it just makes
> >> the specification less readable.
> >
> > Yes, but (a) you have it listed twice in the prototype
> > section, and (b) that is again consistent with what we did
> > elsewhere.  I seem to remember that we argued about it
> > before?  Sorry if so...
> 
> We did - and I think I followed what we agreed to do - two entries in
> the initial summary and then one in the expanded description to avoid
> excessive duplication and increase readability.

I removed it again.


> > For the constructor, I don't see that yet, i.e. I don't see
> > the value of having an additional c'tor without URL, versus
> > having the URL default to an empty string, as we have
> > everywhere else in the spec.
> >
> > Could you please clarify the semantic difference between the
> > two?
> 
> As mentioned above the url is a saga object and so cannot be an empty
> string as that is a a different type.

See above, that is no problem.  


> > As for the session, that is always optional, as described in
> > 3.5.2 in the Core spec - no need to list additional
> > constructors for that either.
> >
> >
> >> It might be worth a phone call - where are you?
> >
> > In  Germany, so roughly the same time zone. :-)  Tomorrow
> > would work, I'll send you my number in a separate mail.
> 
> OK - it may not be necessary. However I would like to get this spec
> out of the way.

Me too :-)

In the attached version, I tried to address the things we
agreed upon, and changed the service types/names table as
proposed.  Could you give it another pass, please?
I left the Constructors untouched for now, until we agreed
on something, ok?

Also, there is a question from me at the bottom of page 5: 

  "Note: Why not TimeOut, AuthorizationFailed, etc??"

Do you have a opinion here?

Thanks, Andre.


> Steve



-- 
Nothing is ever easy.