[gfs-wg] Re: Proposed Final Draft for RNS v1.0

Thu Jun 9 13:47:38 CDT 2005

Hello All,

This message is in response to Osamu's post; I am currently working on a 
response to Ted Anderson's post.  I have posted the most recent revision 
to GridForge, so please reference that version when considering the 
following updates 
(https://forge.gridforum.org/projects/gfs-wg/document/RNS-Proposed_Final_Draft-v1.1/en/2).

> o Behavior of moving an entry whose AliasCount property is greater
>   than one.
> 
> This needs to be described in 1.1.1.2.4 same as the case of deletion.
> Possible solution is we do not allow this, but optionally we allow
> this if and only if TargetPath of all of alias entries is reassigned
> to the new TargetPath.

Good point.  I have added the "move/rename" case to be included in section 
1.1.2.4.

> o Should TargetType in QueryResponse for list and lookup be
>   TargetPath?

Yes, good catch.  Thanks.

> o Behavior of create without Type
> 
> Type is an optional property for create according the section 1.3.2.1.
> If it is not specified, what entry is created?

My original thinking here was that if "Type" was not specified then 
"VirtualDirectory" is assumed (by default).  However, perhaps requiring 
the "Type" parameter as a mandatory input is less confusing.  "Type" is 
now mandatory.

> o Value of AliasCount
> 
> In 1.1.2.4, there is a description '... greater than one ...'.  This
> means AliasCount is one even though there is no alias entry that
> points to.  For me, zero is fine in this case.

You are correct, this was a mistake; it should be "...greater than 
zero..."

> o SoftAlias, HardAlias, and PathAlias
> 
> In VFDS specification, there are SoftAlias, HardAlias, and PathAlias.
> On the other hand, RNS specification only specifies Alias Junction.
> Is it still possible to support these three types in VFDS based on
> RNS?

This is basically the result of opting out of specifying the use, format, 
uniqueness, mutability, etc. of OIDs in this specification, in favor of 
using globally unique hierarchical path names.  As a result, the RNS 
"Alias" has become more like a hardlink, while the function of VFDS's 
"PathAlias" can be accomplished by using a "Referral" object.  Lastly, by 
specifying a "SoftAlias" property within the GFS Naming Profile, a symlink 
behavior is attainable.

[Additional Questions]

> o 1.1.2.4 Alias Junction
> 
> It is better to mention the case when an entry referenced by an alias
> junction is also an alias junction.  In this case, RNS can modify the
> target path, or a client needs to traverse multiple aliases.

I like this idea.  This option is now available in both the list() and 
lookup() operations by using the "AutoResolve" parameter.  See sections 
1.3.2.3 and 1.3.2.4.

> Moreover, when we allow an alias junction to a virtual directory,
> there may be a loop in directory tree.  Since an alias junction only
> points to an entry within the same service, we can check this in
> create operation.

Sure, we can require that the service check to see if the alias 
"TargetPath" points to any direct ancestor in the hierarchy, or points to 
another alias that points back to the alias being created or to any direct 
ancestor of the alias being created.  This description was added to 
section 1.3.2.1.

> o 1.3.4 Context Operation
> 
> openContext requires IteratorContextID to create a context.  Why
> should this IteratorContextID be specified?

I have made this parameter optional, thereby requiring that the service 
generate a unique point-in-time identification string if a context id is 
not specified in the list operation.  This context id is then included in 
the IteratorContextResponse message (notice that I changed the request and 
response message names to IteratorContextRequest and 
IteratorContextResponse respectively, due to the following question and 
corresponding answer).

> How to ensure the
> uniqueness of the ID not to conflict among clients?  EPR returned by
> openContext cannot be used for this purpose?

I originally implemented a very simplistic design that allowed the client 
to specify the context id, and if it didn?t exist, the service would 
automatically create a new context using the specified context id.  In 
this model, the client does not know if the context id already exists or 
not.  In an attempt to address this issue, I have split the openContext() 
operation into two operations: createIteratorContext() and 
getIteratorContext().  Very simple, the createIteratorContext operation 
only creates contexts, allows the caller to not specify a context id, and 
returns a fault message if a context id is specified that already exists. 
The getIteratorContext operation only retrieves existing contexts, 
requires the context id parameter, and returns a fault message if a 
context corresponding to the context id specified does not exist.

This approach will ensure the caller that the context id specified will be 
unique to his request.  Remember that these ids are temporal and are 
immediately discarded once the EPR associated with them is destroyed, 
which is immediately following the completion of a list() operation.  The 
iterator context id can be considered analogous to HTTP cookies.

> o 1.5.1.1 Referral Messages
> 
> This functionality would be applied to Endpoint Reference Junction and
> Virtualized Reference Junction when a path traverses a junction entry.
> I believe it would be nice to extend this feature to them.

This is a feature of any ?query? operation, and is presented by the 
QueryResponse message.  Does this help, is there any question about this?

> o '.' and '..'
> 
> This document does not mention about '.' and '..'.  These entries are
> (automatically) included in Response of list operation?  Can we
> include '.' and/or '..' in Path?

Very good question.  ?.? and ?..? are not discussed in the service 
specification because these two special hierarchical directory notations 
are not necessary for the service since they should be resolved and 
interpreted by the client application.  The client should always present a 
fully qualified pathname to the service. I do strongly believe that any 
implementation that offers a POSIX like interface to the global namespace 
should incorporate ?.? and ?..?; in fact our reference implementation 
does, but it is not part of the service semantics.

> o Path and Name
> 
> As Ted also pointed out, I think Name is redundant and not necessary.
> Is it better to omit Name in Input?

I have tried to clarify the function of these two parameters in the latest 
revision of the specification.  If Name is used, it is not redundant, but 
offers a create( parentDir, entryName ) feature.

?If Name is specified, the service will implicitly appends the value of 
Name to the value of Path to derive the absolute path of the entry to 
create; if Name is not specified, the service simply uses the value of 
Path as the absolute path of the entry to create.?

> Regarding the teleconference, unfortunately I will be in Seattle in
> that week.  Since it will be a very short stay, I am not sure I can
> make it in this week.  Moreover, the deadline to submit a document is
> May 27...

What can we do at this point?

Thank you Osamu for your review.

Best regards,
Manuel Pereira
===============================
IBM Almaden Research Center
===============================
650 Harry Road, San Jose, CA 95120 
1-408-927-1935  [T/L 457]
Pager: 800-946-4646 1492425
http://mvp3.almaden.ibm.com
mpereira at us.ibm.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20050609/609e3dbd/attachment.html 