2008/12/17 Andre Merzky <andre@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