{
\catcode`\ =\active
\catcode`\^^M=\active
\gdef\beginverbatim{\begingroup%
\def\\{\char92}%
\catcode`\ =\active%
\catcode`\^^M=\active%
\catcode`\$=12%
\catcode`\&=12%
\catcode`\^=12%
\catcode`\#=12%
\def {\ }%
\def
{\hfil\break\noindent\strut}%
\tt}}
\let\endverbatim\endgroup
\catcode`\@=\active\def@{\beginverbatim\let@\endverbatim}

Recent development in naming in distributed systems makes it clear
that names should transcend machine boundaries, and that files are not
the only thing that we want to name.  Sprite introduces a
machine-independent naming scheme, but only for files. Windows NT
introduces a heirarchical structure that includes many kinds of
``objects'', but they are limited to being of classes predefined by
the NT ``micro''-kernel, and names are only meaningful on a given
machine.

The operating system of the future will have a namespace organized in
a heirarchy.  Like Sprite, a fully-qualified name will have a meaning
independent of the machine interpreting the name.  However, names will
be allowed to contain enviornment variable references whose meaning is
host- (in fact process-) specific (such names are not fully-qualified;
performing the variable substitution results in a fully-qualified
name).  This way it is possible to deal with things such as different
binary types, multiple sources of system software, or the desire to
store a temporary file on a local disk.  For example, the object name
@/edu/mit/athena/local/$localhost/fs/tmp/foo@ would name a temporary
file on the current host, and the object name
@/edu/mit/lcs/system/$cluster/$hosttype/bin/ls@ might name the @ls@
program.  I could access a file stored locally on a nearby host with
the pathname @/edu/mit/athena/local/w20-575-13/fs/tmp/bar@.

Administration of a global namespace would be accomplished as follows.
The first several levels of the heirarchy indicate the name of the
administrative domain in which the object exists; objects must live in
exactly one administrative domain.  The objects at this high level are
{\it container} objects; their only purpose is to contain other
objects, and the only operations that most users perform on them are
{\it list} and {\it search}.  These top-level objects are read-only,
and can thus be highly replicated and cheaply cached.  This mechanism
distributes the task of administration in the same way that the
Internet host namespace does.

The fundamental operations performed on a name are {\it substitute}
and {\it resolve.} Substitute, as mentioned above, turns a name with
variable references into a fully-qualified name.  Resolve converts a
name into an {\it object identifier}.  This identifier is enough
information for the process with the name to call methods of the
object.  A {\it name-resolution server} will run on each node for this
purpose, much in the way a @named@ process runs on every host using
Internet name service.  The name-resolution server keeps track of
where objects are located, and also keeps track of which objects exist
on the current machine.  However, it is the responsibility of a
container object to be able to locate its children.  Specifically, if
a container object receives a {\it search} request for a name it
contains, it must be able to provide that name's object identifier.

For example, consider a distributed file system.  The object
@/edu/mit/athena@ is a replicated, read-only container object with an
entry @home@, which is itself a replicated read-only object with an
entry for each username.  Each workstation at MIT is permanently
configured with the locations of the @/edu/mit/athena@ object (this is
how Internet DNS works).  
Now say I access a file in my home directory,
@/edu/mit/athena/user/kkkken/sounds/burp@.  This is the first file
access I make on this workstation, so its local name-resolution server
asks one of the @/edu/mit/athena@ replicants where to find @home@;
an object identifier is returned.  It then asks this object for
@kkkken@, and so on down the chain, much like NFS. 

Things other than files can be stored in this system.  For example, to
kill a process on my machine, I could call the {\it kill} method on
@/edu/mit/athena/local/m16-034-11/proc/kkkken/134@, perhaps.  Of
course, variables could be set up so I would merely need to type
@$domain/local/$host/proc/$user/134@ or even @$myprocs/134@.  One nice
thing about the system is that if I accidentally left a process
running on another machine, I could easly find it and kill it without
remotely logging in.  I would expect all user-visible operating system
data structures to be accessible via object names, including machine
performance statistics, access to local daemons, and objects such as
semaphores, message queues, and named pipes.

Issues I haven't addressed are access control and caching of
read/write objects.  Kerberos works pretty well for access control;
objects can maintain access control lists and use kerberos to
establish the identities of principals making RPC requests.  Maybe the
Sprite system works well for caching, I don't really know.