Legion is an object-based system organized by classes and metaclasses (classes of classes). All Legion classes are objects. Legion objects are organized by their classes and the classes are in turn organized into a hierarchical structures of metaclasses . The top metaclass is the LegionClass, which is responsible for every object in the system.
Every element of Legion is represented by a Legion object. You work in Legion by controlling the desired resource's representative object. This means that you must have an name for the object that you wish to use. An object can have two kinds of names: a system-level LOID or a user-assigned context name (Figure 1).
All Legion objects are automatically assigned system-level names called Legion Object Identifiers (LOIDs). You can use LOIDs from the command line, but they are, at best, impractical and awkward (see About the LOID).
Or, an object can have a context name. A context name is a string name that you assign to a Legion object. You can assign multiple names to a single object. An object can be assigned different names by different users. Context names are organized into a hierarchy of contexts in Legion's context space. Contexts are organized in sets of subcontexts, just as Unix directories are organized in sets of subdirectories.
Objects are not automatically given context names: new Legion systems provide a starter context space with names for existing objects. When you create new objects, you can assign them context names. You can run programs, use far-flung resources, and take advantage of Legion's other features through context space. Figure 2, below, shows a typical new Legion system's context space. You will probably be given a portion of your system's particular context space as your personal space.
A typical new system includes a context hierarchy and context names for commonly used objects. This provides context paths for key objects, such as classes and implementations. These objects are in the /hosts, /vaults, /impl, and /class contexts. I.e., class objects are in the /class context and implementation objects are in the /impl context.
Context space is not related to physical space or object types, since context names are assigned and organized according to users' needs, not object's physical location or description. Objects in the same context do not have be able to communicate with each other or even know of each other's existence. They do not have to be the same type of objects. A context can hold multiple subcontexts, just as Unix directories hold sets of subdirectories.
Context path names use Unix-style slash ("/") by default, and the examples here follow that style (e.g., the full context path name for the bootstrap host in the system shown in Figure 2 is /hosts/BootstrapHost).1
You can see a working context space in the npacinet browser at <http://sirius.cs.virginia.edu/browser> as a guest user or, if you have a npacinet account, under your account name (npacinet is our testbed: see <http://legion.virginia.edu/npacinet.html>).