
Here are a few responses to Andrew's critique. On 7/20/2005 14:55, Andrew Grimshaw wrote:
1) The basic directory function is to provide a mapping handle f("string"), i.e., to map strings to some form of handle.
Thus, in section 1.1.
Why do we need four different types of junctions? Should we not have one type of junction: mainly to an EPR. Thus a directory would map a string to an EPR.
EPR f("string");
Instead there are four "types" of junctions:
EPR's
Virtualized reference - either contains an EPR or a URL that points to some other service
Referrals - point to another RNS service. Q: could this not be modeled as an EPR?
Alias - points to another "entry" within the "same" RNS service. This seems to imply a container like model - more on this later.
I suggest that we need only ONE type of junction - an EPR. That will simplify client coding - and the model significantly.
I don't think one type will do. One of the key features of RNS is the three level naming architecture. The first level pathnames map to logical names, which are subsequently mapped to resources in the form of EPRs. This level of indirection through logical names allows important flexibility and separation of responsibility. The "everything is a resource" manta can be taken too far, however, and I don't think it makes sense to have logical names be resources. Thus one of these junctions maps to a logical names. Not everyone wants or needs a three level naming structure, so RNS has provision for direct mapping from names to resources. This would justify another type of junction.
2) Implied model - Repositories
There is a notion in the spec of "same service instance" that in conversations has also been called a "repository". The basic idea is that an RNS service may "contain" a set of directories - and that the service has a root. Thus junction types distinguish, for example, between internal and external things that they point to. Thus an RNS service is a rooted tree - that may point at the leaves to other rooted trees. So, first of all - it is implied. If we're going to have that model it should be right up front and discussed. What is a repository? What are it's special port types if any, etc. Second, I think that it is not the right way to think about the problem. Directories should be the resources - not collections of directories. If a particular implementation chooses to multiplex a large number of logically independent directories in a single container - great - we will certainly do that too. The issue is what is the model. I feel fairly strongly about this.
I agree that RNS instances, or repositories, should be given more explicit treatment. An RNS instance is a collection of namespace objects and has some important properties that should be described and motiviated more clearly. I think this is a real and important concept in the naming model and should not be hidden behind a directory-only idealization. In a hierarchical namespace each name represents a kind of delegation for naming of subsequent components of a pathname. Since each directory can have different authorization rules (e.g. permissions, ACL), this delegation has real meaning: someone else now controls the meaning of all names with this path prefix. An RNS instance is contained within a single administrative domain, so delegation of namespace control within an RNS instance is bounded by that domain. When a namespace mapping delegates to a different RNS instance, something important is happening. A whole new organization has received reponsibility for controlling the meaning of subsequent pathnames. This sort of transfer needs to have explicit representation in the namespace and a specific junction type seems like a reasonable way to do this.
Links "into" other RNS servers:1.1.2.4 "Alias Junction" is restricted to pointing to entries in the same repository. I think they should be able to point to anything - including directories in "other" repositories. It has been claimed that using the EPR of the "repository" and a path you can get that effect. However, what if the path changes in the other container? My link would break - even if the directory itself still exists.
Maintaining the hierarchical structure of the namespace means limiting arbitrary connections between directories. While using hierarchical names is a restriction, it is also a valuable simplification. It is easier to understand and maintain. It also follows an important aspect of the real world, namely hierarchical control within organizations. Clearly, non-hierarchical references are sometimes important, but it makes sense to clearly identify these links so that can be treated differently when the hierarchical nature of the namespace is important. Thus aliases that represent symlinks make sense as a separate junction type. Ted Anderson IBM Almaden Research Center