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

[Andre Merzky]

forgot the attachement... *blush*

Andre.

Quoting [Andre Merzky] (Dec 17 2008):
> Date: Wed, 17 Dec 2008 22:44:42 +0100
> From: Andre Merzky <andre at merzky.net>
> To: Steve Fisher <dr.s.m.fisher at gmail.com>
> Cc: Andre Merzky <andre at merzky.net>, saga-rg at ogf.org
> Subject: Re: Service Discovery spec updated at last ...
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_sd.pdf
Type: application/pdf
Size: 151899 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20081217/8be90f65/attachment-0001.pdf