[GFS-WG] RNS Clarifications

Mark Morgan mmm2a at virginia.edu
Mon Feb 5 09:46:19 CST 2007


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



More information about the gfs-wg mailing list