[gfs-wg] GGF14 Session Minutes & RNS comments

Manuel Pereira mpereira at almaden.ibm.com
Fri Jul 8 14:54:51 CDT 2005


Hello all,
 
The post GGF revision of the RNS specification draft has been posted to GridForge:
https://forge.gridforum.org/projects/gfs-wg/document/RNS-Proposed_Final_Draft-v1.6/en/7
 
Please refer to this version when considering the following comments.
 
The following comments are in response to both the posted meeting minutes as well as Osamu’s last message posted to the mailing list.
 
======================
[Meeting Minutes Session #1]
C: ExistFault (create), TypeFault (update) are required.
 
(Response)
A new RNSEntryExistsFault has been added to the specification (section 1.4.6).  In an attempt to keep error handling simple and to strive to keep the least number of faults as reasonable, and since I did not find any truly compelling reason to add a TypeFault, it was not added.  In the update operation, an RNSDirectoryNotEmptyFault is thrown if a VirtualDirectory is not empty.  With this condition in place, there should be no technical problem updating one “Type” to another.
 
======================
 [Meeting Minutes Session #2]
 
1.1.2.3 Referral Junction
 
C: Referral Junction can be broken.  Need to add a note in the
document.
 
(Response)
This has been added.
 
-----------
 
Q: Do 255 characters in length in Section 1.1.3.2.3 mean 255 bytes or
255 unicode characters?
A: 255 unicode characters.  It is for each entry name between '/' and
'/' not for an entire path name.  That should be enough.
 
(Response)
Unicode has been specifically noted.
 
-----------
 
1.2.2.2.1 Required Entry Properties
 
D: Why is 'TargetPath' specified by 'Absolute path'?  An absolute
path can span several RNSs.  Instead, 'relative path' is good
enough since an alias entry points to an entry within the
service.  This issue needs to be discussed further.
 
(Please see comment in response to Osamu’s post below)
 
-----------
 
1.3.2.1 create
 
C: 'Exact one type (LogicalReference, EPR, ...' below the table
should be 'Exact one type (LogicalReference, Junction, ...'.
 
(Response)
Changed, thank you for catching that!
 
======================
[Osamu’s group’s comments]
 
* Both "SetMultipleResourceProperties" in paragraph 3 in Section
1.2.1, and "SetResourceProperty" in paragraph 4 in Section 1.2.1
should be "SetResourceProperties"?
 
(Response)
Again, good catch.  It has been corrected; thank you.
 
-----------
 
* endOfList in QueryResponce is not used by lookup operation.
minOccurs of endOfList should be 0 instead of 1?
 
(Response)
This may be a matter of preference.  By changing the minOccurs value in the WSDL, the property becomes optional, which changes its datatype from a primitive boolean to an object (Boolean in Java).  This means that the property is nullible, which I agree is an arguably preferred behavior since the only namespace operation that utilizes this property value is the list operation.  In short, I have changed it to an optional property.
 
-----------
 
* Is a wite space ' ' a non-readable characters in Section 1.1.3.2.2?
 
(Response)
The spec now addresses the space character (ANSI 32).  Should we explicitly specify any others?
 
-----------
 
* TargetPath in Reference Properties is now an absolute path that can
span multiple RNSs.  This means a TargetPath can be changed when one
of the parent virtual directories is moved.  When an RNS does not
have capability to update TargetPath property, it is not allowed to
move one of the parent virtual directories even though AliasCount of
the moved entry is zero.
 
Even when an RNS has the capability, how to compute the new
TargetPath is a problem.  Usually the absolute path can be computed
by going up to the root, on the other hand, since there is no
backward link for a referral junction, it is not possible, isn't it?
 
This problem can be solved by using a relative path in TargetPath,
since it should be within an RNS.

(Response) 
After giving it some consideration, I do agree that the value of the TargetPath property should be relative, or as the document states, it is a “full path” (see section 1.1.3.1.1).  In defense of the path scope consistency argument (an argument against using a relative path), we may consider the following:
-          This is the only exception in the specification that does not use an absolute path.  
-          All path values that are used for input are consistently absolute paths.
-          Since an Alias is only valid within a given service instance, a service instance scoped path (or full path, which is a path relative to the current service instance) seems very reasonable.
 
======================
 
Thank you all for your time and effort in this endeavor.  Please review and provide any last round comments.  Remember I hope to submit the document within the next week or two.
 
Thank you!
Manuel Pereira
IBM Almaden Research Center
1-408-927-1935 [T/L 457]
mpereira at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20050708/40d9b458/attachment.htm 


More information about the gfs-wg mailing list