[ogsa-wg] RNS experiences document

[Andrew Grimshaw]

Osamu,
I'm going to include my comments responses below after [Andrew Grimshaw]

> -----Original Message-----
> From: Osamu Tatebe [mailto:tatebe at cs.tsukuba.ac.jp]
> Sent: Thursday, August 23, 2007 5:07 PM
> To: Andrew Grimshaw
> Cc: gfs-wg at ogf.org; ogsa-wg at ogf.org; 'Mark Morgan'
> Subject: Re: RNS experiences document
> 
> Hi Andrew,
> 
> I appreciate your work on the experiemce document.
> 
> RNS spec basically intends "entry" implementation.  This comes
> from a discussion such that every entry would be pointed by
> an EPR.
> 
> > Note that if the "entry" implementation is used, that after the "add"
> is
> > performed there is no way to subsequently look up or find the EPR of
> the
> > entry! We therefore use the "obvious" implementation.
> 
> How do you solve this problem with the "obvious" implememtation?
> I guess the difference of the "obvious" implementation and the
> "entry" implementation is a returned EPR when a virtual directory
> is created.  I think you need some additional arguments for
> some operations.
[Andrew Grimshaw] 
I'm not sure why we need the fiction of an EPR of the entry itself. Unless
you are going to do operations on it - why have an EPR. If you wanted to
keep it around, I suppose you could keep it in the {any}* part of the
rns:entry, i.e., along with the entry reference and the entry_name.

It seems to me that the only operation you need to perform on the entries
themselves in the current spec is the "query" operation. Our approach has
been to eliminate "query", and instead use "list" to retrieve lists of
<rns:entry>. In the limit, just one in the list. We then parse the XML
ourselves to get what we want out.


> 
> We still need discussion about this, but, is it enough for
> list operation to additionally return an EPR of the directory
> entry itself in case of a virtual directory?
> 
[Andrew Grimshaw] 
I don't understand a "virtual directory" Do you mean another RNS service
instance? That is what the RNS services are!
> Thanks,
> Osamu
> 
> On Tue, 21 Aug 2007 12:44:02 -0400
> "Andrew Grimshaw" <grimshaw at virginia.edu> wrote:
> 
> > All,
> >
> > We have done an implementation of RNS and have several observations
> before
> > we write our experiences document.
> >
> >
> >
> > First, the version of the document I am referring to is the September
> 22,
> > 2006 version.
> >
> >
> >
> > p.4 Add function
> >
> >
> >
> > We're fine with this BUT we had to make some assumptions. You'll note
> that
> > the function returns an EPR.
> >
> >
> >
> > Our interpretation was:
> >
> > In the case that no EPR was passed in, i.e., I'm creating and linking
> a new
> > directory, the function is to return an EPR of a new directory
> resource.
> >
> > If the case that an EPR was passed in, i.e., I'm adding a link to an
> > existing EPR, the EPR that was passed in is returned.
> >
> >
> >
> > We'll call this the "obvious" implementation
> >
> >
> >
> > An alternative interpretation is that a new resource is created for
> the
> > DIRECTORY ENTRY ITSELF. In this case the EPR of this entry is returned.
> >
> > We'll call this the "entry" implementation.
> >
> > Note that if the "entry" implementation is used, that after the "add"
> is
> > performed there is no way to subsequently look up or find the EPR of
> the
> > entry! We therefore use the "obvious" implementation.
> >
> >
> >
> > Both the "entry" and "obvious" implementations have ramifications
> and/or
> > inconsistencies with later parts of the spec.
> >
> >
> >
> >
> >
> > Note on page 7 the pseudo schema for an entry (returned by "list")
> >
> >
> >
> >
> > <rns:entry>
> >
> > <rns:entry_name> xsd:string </rns:entry_name>
> >
> > {any}*
> >
> > <rns:entry_reference>
> >
> > wsa:EndpointReferenceType
> >
> > </rns:entry_reference>
> >
> > </rns:entry>*
> >
> >
> >
> >
> >
> >
> > This is consistent with our "obvious" interpretation.
> >
> >
> >
> > One of the things we have observed is that for very large directories
> this
> > may create messages that are larger than the SOAP max - we may need to
> > extend with an iterator.
> >
> >
> >
> >
> >
> > Also note on page 10 the query operation (which takes NO parameters)
> and
> > returns
> >
> >
> >
> >
> >
> >
> > <rns:EntryProperties>
> >
> > <rns:entry_parent>
> >
> > wsa:EndpointReferenceType
> >
> > </rns:entry_parent>
> >
> > <rns:entry_name> xsd:string </rns:entry_name>
> >
> > {any}*
> >
> > <rns:entry_reference>
> >
> >
> >
> >
> > wsa:EndpointReferenceType
> >
> > </rns:entry_reference>
> >
> > </rns:EntryProperties>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > The implication of query is that the "entry" interpretation is being
> using
> > because there is no way to tell the directory which entry to return
> data
> > about therefore the SOAP headers contain the target in the form of a
> > ws-addressing epr. In other words - this query seems to be targeted to
> an
> > entry rather than a directory.
> >
> >
> >
> > The objective of the "entry" implementation seems to be to work with
> query.
> > The only stuff that seems to be added is the concept on a "entry
> parent" EPR
> > - which in our opinion could be placed in the {any}* part if needed
> (the
> > whole notion of parents is a bit problematic; it is likely to be a
> list not
> > a singleton, and using it for garbage collection is difficult in a
> > distributed system.)  Thus, query seems mostly to be a highly specific
> form
> > of list.
> >
> >
> >
> > Thus, we have chosen the "obvious" implementation. That means that the
> query
> > operation makes no sense by itself (beyond "list") and we have not
> > implemented it.
> >
> >
> >
> > Page 8, move
> >
> >
> >
> > Move takes two parameters, a target directory and a "new" name for the
> > entry, i.e., file1. This seems to imply an "entry" implementation.
> However,
> > that means the client must be keeping track of the EPR's of the
> entries in
> > order to do a move. That's the whole point of a directory services.
> > Therefore, we believe that move should be an operation on a directory
> (i.e.,
> > the EPR of the directory is in the SOAP header) and take two
> parameters, the
> > old name and the new name - in other words this is a rename.
> >
> >
> >
> > Finally, from a interoperability point of view the fact that the RNS
> spec
> > does not include a normative specification of the schema/WSDL, we
> don't
> > believe that it is likely for interoperable implementations to exist
> solely
> > based on the spec.
> >
> >
> >
> > Modulo the above changes we have an implementation of RNS (we don't
> think
> > that given the existing spec it is possible to completely implement
> RNS as
> > specified) and a set of tools that interact with RNS name spaces,
> command
> > line tools for ls, mkdir, etc, as well as a Linux file system software
> shim
> > that intercepts file system calls and redirects (when appropriate) to
> > RNS/ByteIO space.
> >
> >
> >
> > A