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

[Steve Fisher]

2008/12/17 Andre Merzky <andre at merzky.net>:
> 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 :-)

I see your point - however this implies that a list_services call must
always return "complete" services such that get_url() will succeed. I
think this is reasonable so I accept your suggestion


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

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. I
guess the same is true for the logical file service. If this is the
case the table was fine as I had it!
>
>
>> 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?

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.



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

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 "".
Whatever syntax is appropriate for an optional session parameter is
also good for an optional url parameter.

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.



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


>> 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 mentioned above the url is a saga object and so cannot be an empty
string as that is a a different type.

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

Steve