Hi,
I support multiple intersecting, overlapping, disjoint, etc. namespaces on a distributed system. My conceptual model for the namespace consists of three different types of "things" (avoiding the term "objects"):
- namespace
- bag
- terminal
A namespace is a hierarchy of names. E.g., "/" on traditional Eunices.
A bag is an object (grrr) that holds other bags -- or terminals. E.g., a "directory" ("folder" for folks who had the misfortune to grow up in a MS world).
A terminal is ... a "leaf" -- the actual "thing" being named.
All of these are *active* objects ^H^H^H "things".
It is important *not* to think of these as "filesystems", "directories" and "files". Many of them are not persistent, etc.
Two namespaces can overlap, intersect or be completely disjoint. A name in one namespace (for a bag *or* a terminal) need not agree with the name used for THAT SAME OBJECT (grrr "thing") in some other namespace. (think of how symlinks work, for example).
I handle name resolution by passing a "description" (akin to a pathname/filename) to a name resolver for whichever "thing" the description is rooted in/at. E.g., I could pass "foo/bar/baz.txt" to the "thing" rooted at "/usr/dgy/" to give the recognized behavior of "the file located at /usr/dgy/foo/bar/baz.txt" (again, remember file is just to make this seem more familiar in this explanation). I could, similarly, pass "/usr/dgy/foo/bar/baz.txt" to the thing at the *root* of (a particular) namespace to get to that same "thing".
Now, the nitty gritty:
Each "thing" (remember, these are active entities) looks at the description passed to it and applies its own syntactic rules to the interpretation of that "description". So, when a "bag" (again, think just in terms of a bag being a "directory" in a "disk file system") gets handed "foo/bar/baz.txt", it's semantics *know* that anything residing in that "bag" will not contain a '/'. Said another way, it can strcspn() the string looking for '/' and take everything up to that '/' as an identifier for a "thing" residing in that "bag". (e.g., "foo")
If it discovers that "foo" does, in fact, reside in this "bag", it removes "foo" (plus the '/') from the description and passes the remaining portion of the description to "foo" (i.e., to the active object that implements the "foo" bag). Then, "foo" applies its syntactic rules (which, for sake of example, are the same as its predecessor) and strips "bar" off the head of the description and passes the remaining tail to "bar".
I.e., each "bag" can apply whatever syntactic rules it wants to the "descriptions" it processes. For example, the "foo" object might force all identifiers for objects in it's "bag" to be exactly 5 characters long (!). As such, it looks for "bar/b" as an indentifier for one of the items (presumably) contained in it's bag. Finding it, "az.txt" is passed to "bar/b" as the balance of the description.
The important thing, here, is that the syntax of items within a "bag" is defined by the bag itself (i.e., there are various flavors of "bags"). And, the manner in which a particular flavor of bag processes the description that is presented to it is left up to that bag to decide.
It should be obvious that traditional filesystem names are just "special cases" of this algorithm. I.e., in UN*X, "look for everything up to the first '/'"; in DOS, "look for everything up to the first ''"; etc. (obviously, there are special cases -- especially in the MSbraindamage world!)
The issue that I am trying to address is how to handle "go up a layer" in the namespace.
Note that specifying a valid name "in my world" requires knowledge of the syntax imposed by each "bag" encountered on your way to a particular terminal. Context is very significant (it is intended to be as each bag can be a different "thing" in functionality, etc.).
And, there is *nothing* that is "special" in any of my "descriptions". There isn't even a notion of '/' (root)!
So... the idea of adding *a* special designator *just* to reference "up" really is grating. First, the typical notation ("..") is expensive -- two (actually three) characters just to represent one simple concept. (granted, I could opt for the '