[GFS-WG] RNS Clarifications

[Osamu Tatebe]

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
>