NamingSystem

UserPreferences

1 An Introduction to PEAK Naming Services

What's a naming system, and why do you want one for your programs? Naming systems let you use names instead of addresses to refer to the objects you use. Whether the objects in question are database connections, printers, documents, or distributed object services, replacing addresses with names makes programs clearer, more flexible, and easier to maintain.

1.1 Names vs. Addresses

What's the difference between a name and an address, and why is it important? A name tells us what something is, or is for, while an address tells us how to get to it. This is significant because "how to get to" something can change far more quickly than what it "is".

Let's say we are in a grocery store. I could either say, "go to the back of the store, aisle 4, top shelf, right-hand side, fifth can," or I could simply say, "I'd like a can of spam please." Obviously, if the store is later reorganized, my "address" for spam may have to be changed, but as long as it's still called spam, I can always ask a clerk or look at a store directory.

Of course, this means that I must go through an intermediary to obtain my spam, rather than going directly to it, but that is the price I pay for the flexibility.

Notice this also means that names are context-sensitive. That is, the interpretation of a name can vary according to the context. Asking my grocer or my e-mail client for "spam" will produce very different results. But an address is context-independent, and will always refer to the same location, although what is in that location might change over time.

Names	Addresses
What an object is or does	How to find it
May be human-friendly format	Often detailed and difficult to read
Long-lasting	Transient, may change for a given object
Must be resolved via a naming service	Allows direct access
Context-sensitive	Context-independent

1.2 Contexts, Naming Systems, and Federation

A context is something that provides a mapping from names to objects. For example, a directory in a filesystem is a context that maps from filenames to file and directory objects. Contexts may provide a variety of operations for using or managing the mapping from names to objects. For example, one can create subdirectories of a directory, add or remove files, etc. Here are some examples of naming contexts:

Example Context	Example Names	Extra Services Examples
Filesystem	/usr/bin /home/somebody/foo	Create or read symbolic links Set access privileges
LDAP Directory	cn=Phillip Eby,o=eby-sarna.com cn=Copier,ou=Accounting Department,o="BigCompany, Inc."	Store data associated with names Search for objects based on associated data
DNS	cvs.eby-sarna.com peak.telecommunity.com	Multiple records per name

Different contexts follow different naming conventions and syntax for their names. As you can see from the examples, these conventions and syntax can vary considerably. DNS names, for example, are hierarchical from right to left, with the name parts separated by dots. UNIX filesystem names, on the other hand, are hierarchical from left to right, and use '/' as a separator. Some naming systems are "flat", and do not have a hierarchy or separators at all.

A set of conventions for naming, and the contexts that implement those conventions, are called a naming system. Naming systems that use hierarchical names can have contexts contained in other contexts, in the sense that a /usr/bin directory can be contained inside a /usr directory.

While most naming systems are quite useful by themselves, it is also often useful to combine them. For example, you are probably accessing this page via a combination of a DNS name (peak.telecommunity.com) and a filesystem name (/DevGuide/NamingSystem). Names which incorporate parts from more than one naming system are called composite names, and the process of combining naming systems is called federation.

1.3 Compound and Composite Names

Hierarchical, path-like names are called compound names

XXX etc...