Hello Osamu,
> Now, all input to the service becomes a full
path.
Actually it always has been, however
it has been presented in such a way that describes the use of an absolute
path in all cases; this was done in an attempt to reduce complexity, potential
confusion in a federated namespace, and present a consistent globally unique
identifier for all namespace objects.
(In Section
> 1.3.3.1 "move", there still "the absolute path"
remains in the second
> table.)
Right, I was originally thinking of
allowing "moves" to occur between RNS providers, however this
is simply not facilitated by the specification; a provider-to-provider
interface would have to be described and that is out of scope for this
revision.
It is now changed, thanks!
> This means the absolute path is only handled
by a client
> library not by a service itself. A service does not care about
the
> absolute path. Root directory is only known by a client. I
do not
> think there is any problem about this.
If "handled" means that the
client is the only party that maintains a comprehensive view of the overall
federated namespace. The first sentence in section 2.2.1.1 clearly
states that "all service operations
[MUST] accommodate the use of absolute pathnames."
This section goes on to describe how the referral message mechanism
is employed to allow dynamic redirection to the appropriate RNS service
providers if the path provided is not served by the current provider.
> (In Section 1.4.6 "RNSJunctionFault",
and in the first paragraph of
> Section 2.2.1.1 "Referral Messages", "absolute"
path should be "full"
> path?)
Please see the comments above, these
two cases are correct and still valid.
> Can we have a teleconference on Friday afternoon
(3pm or 4pm) in
> California time?
This is a good idea and the time should
work for me.
Best regards,
Manuel Pereira
------------------------------------------------------
IBM Almaden Research Center
1-408-927-1935
[Tieline: 457]
mpereira@us.ibm.com
------------------------------------------------------