[GFS-WG] RNS Clarifications

Tue Feb 27 00:15:38 CST 2007

Hi All,

Attached is a document that reflects Mark's comment.  Also,
"update" operation is slightly modified to make it possible
to update "metadata" in each entry.

Any comment are welcome.  I will upload this version to the
tracker tomorrow if there is no argment.

Thanks,
Osamu

On Wed, 14 Feb 2007 14:10:44 +0900 Osamu Tatebe <tatebe at cs.tsukuba.ac.jp> wrote:

> Hi Mark,
> 
> Thanks for valuable comments.
> 
> > First of all, is there any WSDL/Schema available?  It seems difficult to
> > produce interoperable implementations without normative schema.
> 
> Right.  We need a basic profile rendering document for RNS.
> 
> > I found it a little confusing reading through the document about when an EPR
> > was referring to an RNS entity (junction or virtual directory) and when it
> > was referring to an entity referenced by a junction.  If you'll permit me,
> > allow me to go through each operation in turn.  Following this, I have a few
> > more generic questions.
> 
> An RNS entry is either a junction or a virtual directory.  A junction has
> a target address 'entry_reference' like a symlink, while a virtual directory does not have it.
> 
> A junction 'foo' has any target that may be another RNS entry 'bar' (junction or virtual directory).  This was called a 'referral junction' in the previous specification.  In this case, a junction entry of 'foo' itself is returned by a query operation to the EPR to 'foo', which include all EntryProperties including entry_parent, entry_name, entry_reference and other entries.  If you would like to know about the target, you need to query against the target address.
> 
> Does it make sense?  I guess you probably think a junction like a hardlink, but it is more like a symlink.
> 
> > List:
> > 	Does the list operation return RNS entities, or the things that they
> > refer to?  Since I'm assuming that virtual directories are entities, but
> > non-directories are not, I'm guessing the answer is that sometimes it
> > returns a virtual directory, other times it returns the entity references by
> > a junction?
> 
> The list returns all entries in the specified virtual directory.  For example,
> the list of 'dir' returns list of entries: 'foo', 'bar', 'baz', when a directory structure is as follows;
> 
> dir/foo
>     bar/bar1
>     baz
> 
> where 'dir' and 'bar' are virtual directories, and 'foo', 'baz', and 'bar1' are junctions.
> 
> > Move:
> > 	Given that this operation doesn't identify in its parameter list the
> > entity to move, I'm guessing that that is implicit from the WS-Addressing
> > headers.  In otherwords, I'm assuming that move is targetd either at a
> > virtual directory or a junction.  Once again, which EPR is returned from
> > Move?  Since the virtual directory or junction which is a target of this
> > move is not affected itself (in terms of its own adderss), wouldn't this be
> > identical to the target entity used for the move operation?  If so, what is
> > the return value supposed to be used for.
> 
> The EPR of the moved RNS entry is returned.  'Entry_reference' is not changed but a location of the RNS namespace is changed.
> 
> > Query:
> > 	Again, like move, the target I'm assuming is implied from
> > WS-Addressing headers right?  In otherwords, queries are run against virtual
> > directories and junctions correct?
> 
> Yes.  The target is implied from WS-Addressing headers.  Also, queries are run against virtual directories and junctions.
> 
> > Remove:
> > 	Since this always takes the name of a contained entry, I'm guessing
> > that this operation is always targeted at a virtual directory, and not
> > junctions.
> 
> Good point!  I will add this description in remove section, and add RNSEntryNotDirectory fault when executed against a namespace junction.
> 
> > 	Is there a reference implementation?  I'd like to see the source
> > code if I could?
> 
> We are now trying to make IBM's implementation available through open sourcing to GT4.
> 
> Thanks,
> Osamu
> 
> On Mon, 5 Feb 2007 10:46:19 -0500 "Mark Morgan" <mmm2a at virginia.edu> wrote:
> 
> > GFS Working Group,
> > 
> > I understand that RNS has made its way through public comment.  Sadly I must
> > confess that while I glanced through the document earlier to gain a high
> > level understanding of the content, it wasn't until this weekend when I sat
> > down and tried to bring our implementation up to date with it that I
> > realized there were some confusions about it.  Given that the document is
> > already through public comment, please view this email as a request from a
> > potential user for clarification.
> > 
> > First of all, is there any WSDL/Schema available?  It seems difficult to
> > produce interoperable implementations without normative schema.
> > 
> > I found it a little confusing reading through the document about when an EPR
> > was referring to an RNS entity (junction or virtual directory) and when it
> > was referring to an entity referenced by a junction.  If you'll permit me,
> > allow me to go through each operation in turn.  Following this, I have a few
> > more generic questions.
> > 
> > Add:
> > 	I'm assuming that the result of the add operation is the EPR of
> > either a virtual directory or a junction.  Is that correct?  In otherwords,
> > if I add the entity
> > 	<Address>http://tempuri.org</Address>
> > As foo to an RNS directory, the EPR that I get back is the EPR of the
> > junction created by RNS for that entity, not the
> > <Address>http://tempuri.org</Adderss> correct?  What if
> > <Address>http://tempuri.org</Address> refers to another virtual directory in
> > an RNS service somewhere?  Does it still get a junction?  How do you tell?
> > 
> > List:
> > 	Does the list operation return RNS entities, or the things that they
> > refer to?  Since I'm assuming that virtual directories are entities, but
> > non-directories are not, I'm guessing the answer is that sometimes it
> > returns a virtual directory, other times it returns the entity references by
> > a junction?
> > 
> > Move:
> > 	Given that this operation doesn't identify in its parameter list the
> > entity to move, I'm guessing that that is implicit from the WS-Addressing
> > headers.  In otherwords, I'm assuming that move is targetd either at a
> > virtual directory or a junction.  Once again, which EPR is returned from
> > Move?  Since the virtual directory or junction which is a target of this
> > move is not affected itself (in terms of its own adderss), wouldn't this be
> > identical to the target entity used for the move operation?  If so, what is
> > the return value supposed to be used for.
> > 
> > Query:
> > 	Again, like move, the target I'm assuming is implied from
> > WS-Addressing headers right?  In otherwords, queries are run against virtual
> > directories and junctions correct?
> > 
> > Remove:
> > 	Since this always takes the name of a contained entry, I'm guessing
> > that this operation is always targeted at a virtual directory, and not
> > junctions.
> > 
> > High level questions:
> > 	I believe that it is the case that two functions can target
> > junctions.  These are move and query.  Since there is no way to acquire a
> > list of junctions in a virtual directory (list I believe returns what the
> > junctions point to), how would you ever get a junction EPR to target?  I
> > guess you could store it after the add operation, but that seems incorrect.
> > Am I missing something?
> > 
> > 	Is there a reference implementation?  I'd like to see the source
> > code if I could?
> > 
> > Thanks,
> > Mark
> > 
> > --
> > Mark Morgan
> > Research Scientist
> > Department of Computer Science
> > University of Virginia
> > http://www.cs.virginia.edu
> > mmm2a at virginia.edu
> > (434) 982-2047
> > 
> > --
> >   gfs-wg mailing list
> >   gfs-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/gfs-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RNS-Specification-20070226.doc
Type: application/msword
Size: 306176 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/gfs-wg/attachments/20070227/8eba3233/attachment-0001.doc 