[ogsa-wg] RNS experiences document

[Andrew Grimshaw]

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070821/b897e3c0/attachment-0001.htm