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

[Andre Merzky]

Hi Steve, 

Quoting [Steve Fisher] (Dec 16 2008):
> 
> >  - removed some exeptions, too, as error conditions could
> >    never occur, I think.
> 
> You have removed "NoSuccess" from the service_description calls. I
> thought this was a catch-all which should almost always be present?

You (implicitely) write that the implementation MUST fill
the URL attribute, so it MUST be available, and a
get_attribute(url) MUST succeed.  Now, get_url is just a
shortcut to get_attribute("url"), so it cannot fail, can it?

OTOH, if you consider that to be fallible (is that English?
;-), e.g. because the backend cannot guarantee state or
whatever, then you probably need to add all possible
exceptions listed for get_attribute from the attributes
interface, not only NoSuccess?  

Or, alternatively, you specify that get_url() maps all
possible get_attribute() exceptions to NoSuccess - then that
needs to be added again of course.  But then again, why not
pass them through?

At it was, it was not clear why that exception was there,
and others like TimeOut was not.  Your call :-)


> You have added a note that the returned list can be empty - but you
> have it as "reurned"

Thanks.


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


> 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?


> Just above this you have added some text with the word "Services" - it
> should be "services"

Thanks.


> 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?  


> As a note on the discoverer constructor you have added "if the URL" -
> to be consistent it should read "if the url"

Thanks.


> Has "IncorrectURLException" now become "IncorrectURL"?

Yes, as of the Core spec, we have removed 'Exception' from
all exception names.


> >  - added a 'Implementation MAY use saga context attrib
> >    names for auth filtering', to clarify that this is not
> >    required (auth filter generation may imply otherwise).
> 
> I see you have rejected 3 of our constructors in favour of 1 with 2
> optional arguments.  I presume the language binding is allowed to do
> it in a way that is natural for that language. You suggest that
> specifying a url as an empty string should be equivalent to omitting
> it.  This offends me - and I think it is wrong in other places in the
> SAGA spec.

Then we should have changed it in the SAGA spec possibly -
but we did not.  I think we should keep that consistent for
the extensions, too.


> So I would like to see something like:
> 
> CONSTRUCTOR (in session session,
>              in url url,
>              out discoverer dis)
> 
> and state that both parameters are optional in the notes.

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.


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


> Perhaps we can agree on  these points of representation before
> checking anything in. I would like to see 1 constructor with 2
> optional arguments (as you have it) - but no default empty string and
> to leave the list_services as one call with an optional argument.

To clarify that again:  arguments with a default value are
optional arguments, e.g. they can be left out when calling
the function.  In your list_services() method, you want to
have an explicit distinction between the two signatures,
i.e. you do _not_ want to have a default argument for the
authz filter - that is why you have two prototypes.  I agree
that this is the right way to do it.

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

Best, Andre.



> Steve
> 
> >
> > Many thanks,
> >
> >  Andre.
> >
> >
> > Quoting [Steve Fisher] (Dec 05 2008):
> >> Date: Fri, 5 Dec 2008 17:59:12 +0000
> >> From: "Steve Fisher" <dr.s.m.fisher at gmail.com>
> >> To: saga-rg at ogf.org
> >> Subject: [SAGA-RG] Fwd: Service Discovery spec updated at last ...
> >>
> >> Hi,
> >>
> >> Unfortunately I have not had any reaction to this. I don't like to
> >> assume that silence means that everybody is happy. Perhaps at least a
> >> co-chair could look through and give me the go-ahead to resubmit.
> >>
> >> Implementation work is due to restart in C++ on Monday and start in
> >> Java on the same date.
> >>
> >> Steve
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Steve Fisher <dr.s.m.fisher at gmail.com>
> >> Date: 2008/12/1
> >> Subject: Service Discovery spec updated at last ...
> >> To: saga-rg at ogf.org
> >>
> >>
> >> Hi,
> >>
> >> I have finally got the spec updated - please see attached .dvi and
> >> .pdf files. Please make any final comments before it goes back to the
> >> OGF editors. Work on implementation will resume next week.
> >>
> >> Steve
> > --
> > Nothing is ever easy.
> >



-- 
Nothing is ever easy.