Public comments are a very important part of the OGF document approval process. Through public comments, documents are given scrutiny by people with a wide range of expertise and interests. Ideally, a OGF document will be self-contained, relying only on the other documents and standards it cites to be clear and useful. Public comments of any type are welcomed, from small editorial comments to broader comments about the scope or merit of the proposed document. The simple act of reading a document and providing a public comment that you read it and found it suitable for publication is very useful, and provides valuable feedback to the document authors.
Thank you for making public comments on this document!
Comments for Document: RNS Specification 1.1
| Author(s): | M. Morgan, A. Grimshaw, O. Tatebe |
| Type: | P-REC |
| Area: | Architecture |
| Group: | OGSA-Naming-WG |
| Public Comment End: | 23 May, 2010 |
Comments:
Posted by: tatebe 2010-05-21 10:36:12rename semantics
We need to clarify the case such that the target entry exists when
renaming the entry name. In the POSIX, it will be atomically
replaced. If we follow the POSIX semantics, there is an undeterministic
condition when renaming multiple entries in a bulk operation. For
example, when there are two rename requests to the same target name,
both requests will succeed but the result is different depending on
which one is applied first.
I guess there are two possible solutions:
1. Do not follow the POSIX semantics. If the target entry exists,
rename fails with RNS Entry Exists Failure.
2. Fix the order of operations in bulk operations. If we assume
operations are processed in the sequence order provided by the
input argument.
renaming the entry name. In the POSIX, it will be atomically
replaced. If we follow the POSIX semantics, there is an undeterministic
condition when renaming multiple entries in a bulk operation. For
example, when there are two rename requests to the same target name,
both requests will succeed but the result is different depending on
which one is applied first.
I guess there are two possible solutions:
1. Do not follow the POSIX semantics. If the target entry exists,
rename fails with RNS Entry Exists Failure.
2. Fix the order of operations in bulk operations. If we assume
operations are processed in the sequence order provided by the
input argument.
login
RSS