Diagram of kernel components.
Interspace Kernel Architecture
The Interspace is a system that seeks to unify disparate distributed information resources in one coherent model. The Interspace , as a entity, is a collection of interlinked information spaces where each component space encodes the knowledge of a community or a subject domain. An information space is a collection of interlinked objects. The basic abstraction of this model is a special object called an Information Unit (IU); this serves as the fundamental unit of organization in the Interspace system. Using IUs as a basis, the system also provides a rich set of support for complex inter-operable applications. Standard services include inter-object linking, remote execution, object caching, and support for compound objects (usually referred to as compound documents.) Additionally the Interspace system acknowledges the importance of legacy applications and provides support for integrating them into the system in a relatively seamless manner. Ultimately, the Interspace system is an attempt to represent all types data/objects in one flexible, cohesive, and scalable system.
The Interspace project is seeking good programmers to implement our prototype system. If you are interested in working on a high-visibility research project to build new information system technology, please send CV to Bruce Schatz.
The Interspace system consists of several layers. The Applications layer involves the interface with the user, the Applications Programming Environment (APE) layer involves the generic services needed for all information applications, the Systems Programming Environment (SPE) layer or "kernel" involves the basic functionality of the information space and IUs. This document discusses only the last of these layers, namely the kernel services. See the attached figure. To write an actual application in the Interspace system, the APE provides a number of simple common objects for use, e.g. documents and databases, and a set of common high-level services, e.g. publishing control and collection analysis.
Information Units are the basic abstraction of the Interspace system, they are intended to be the base encapsulator for all data types. Type Coercer it attempts to remedy the difficulties of converting between unknown data types by introducing a system of wrappers which encapsulates foreign objects thus giving them the appearance of "native" objects. Searching and Indexing are provided as a base part of the Interspace system. Most complex IUs will make indexable version of themselves to allow for search across the Interspace. Display and Interaction IUs have one or more ways of interacting with the user. These interacting units are called views and can be embedded in other views. Communications are controlled and distributed by a number of independent but interoperable components. Events like a mail message arriving to a timer notice are all handled by this system. Structured Type System is responsible for managing the object types in the Interspace system and include a full object description language. Persistent Object Store houses all of the objects in the system and is responsible for managing the interaction between other Interspace nodes and itself. Wrappers are responsible for encapsulating objects outside the Interspace system, hence providing near native interfaces to those objects. External Services maps the services of Internet and standard network communications into the Interspace, thus allowing Interspace objects to communicate directly with the Internet space.
Every user visible object in the Interspace is a descendant or instance of an Information Unit (IU) object. An IU is the fundamental structural unit of all the objects in the system, including such objects as indexing engines, data converters, etc. All IUs have support three major abilities: to display itself, to link itself and to index itself. These three categories of functionality break down into a number of sub components that will be detailed later on in this document.
Objects are displayed and interacted with in any number of ways in the Interspace System. Objects are associated with one or more view IU objects which actually provide the means by which an object is manipulated. Multiple simultaneous views of objects can be embedded into, inside of, any number of independent views of a given IU. A mechanism exists for updating the independent views of an IU when one view changes the underlying object. View IUs also support checking user data entry for correctness and provides mechanisms for displaying correct values to help the user are also defined.
Linking between IUs involves one or more IUs or sets of IUs placed in the link list of an IU. The system provides a default list which is publicly readable and writable. The object itself can then have protected sets of links of its own. Links between objects are 2 way and are represented directly in the objects as references, not as a link object. Linking an IU appears to the user to be embedding the object inside another object. The linking system is completely independent of the inheritance, version and domain systems (i.e. links are not used to represent inheritance, etc.)
Indexing and searching are closely related operations. An IU indexes itself and this process in turn allows the IU to be searched. Several different levels and methods of searching exist. These differing levels and methods allow for alternate search strategies depending on the nature of the data in question. In some cases it is appropriate to do a full text search (documents) and in others a coordinate (2D maps) based is search is more appropriate.
IU objects have a base set of properties associated with them, these include ownership and accessibility. In addition IUs are named and always have a numerical ID associated with them. Names can be human readable but this is not a requirement, certain IUs will have no name at all. Additionally, IUs can have versions of themselves (i.e., older versions etc.), and belong to one or more domains of related IUs. Finally IUs can also be units of functionality, they can be invoked as if the were an independent program, the Interspace refers to this type of an IU as a method IU.
Ownership and accessibility are tied together in the Interspace model by using the abstraction of an accessor. Accessors are IUs which have been placed in the accessor list of a given IU. The evaluation system uses this list when IUs attempt to access the IU in question. Any IU may be placed in the accessor list not just IUs representing a particular user or group of users, a method IU could be placed in the list and this would confer access on that IU. A further detail to note is that accessor membership also applies to any IUs embedded in an IU which appears at the top level of the accessor list (i.e. the children inherit the parents access abilities.) IUs can be owned by several people, each with differing access permissions (although they are all considered equal in that an owner can change any other owners permissions and could even remove another owner from the access list.)
IUs can be versioned, i.e., whenever the IU object changes itself the original version is preserved and receives a new numeric ID. The new version retains the original ID and is then the current version of that IU. Each version of an IU has two time stamps associated with it. The creation time stamp refers to the time when the IU was created, likewise the modification time stamp refers to the last time of modification. Not all objects need to have version retained for them, in this case the modification time stamp is updated every time the object is modified. Versioned IUs, however have there modification time set only once: when the IU is versioned (a change is made). In that case the original IUs modification time is set to the time that the change occurred and the new IUs creation time is set to the time that new IU version is created. This schema presents a window of time in which the IU was considered the current IU. When requesting an IU the default IU returned is the current IU (i.e., the currently active version), if however a point in time or a range is supplied with the request a version, possibly older, of the object is returned. In this way it is possible to possible to look at whole sets of objects as they were at some particular time in the past. Specifying either a time before an IU was created is an error and results in an aborted fetch. Specifying a non-sensical time in the future is likewise an error.
IUs exist inside of other IUs which are referred to as domains. Domains are analogous to directories in filesystems or modules in programming languages. Domains define a name space is which a number of IUs are contained. Additionally IUs can belong to one or more domains, e.g., they can be shared by many domains. In this way domains act as both a localization method and as a way of packaging related IUs. For instance traditional programming libraries might be represented as a domain, similarly a set of user IUs would be contained in a domain like users on a UNIX system are contained in the user filesystem.
Method IUs serve as the basic unit of function in the Interspace system. Method IUs consist of an interpreted or compiled function. These IUs can also be full programs with subroutines, etc., in one enclosing method IU. This allows a method IU to function as a program like entity rather than a discrete function. Most method IUs are contained in other IUs and are considered part of the containing IU proper. This is called a member method IU, or more simply a member method. Since member methods are part of the enclosing IU, when executed it uses the context (scope) of the containing IU as its own, this is the means by which classes are formed and used. Methods that are not explicitly part of an IU, class, are referred to as generics (it is possible to have generics in a class, but this feature should only be used in carefully controlled circumstances.)
The Interspace in essence is a system based upon a unified object model called an IU. IUs in turn are used to define all of the functionality in the system. By using this IU abstraction the Interspace system is both flexible and highly integrated at once. Furthermore the applications environment with its inclusion of searching, linking, access control, wrapper system, and other functionality provides a complete foundation for the development of powerful and interoperable applications.
WrapperIUs encapsulate external objects and give them all or most of the functionality of native IUs. Linking and the other functions of IUs then take place not on the data encapsulated but on the encapsulator (the wrapperIU.)
Important issues of how to map the namespaces to one another is primarily an applications concern, depending mainly upon whether or not dynamic mapping between the namespaces is occurring (some of dynamism will be needed in most non-static systems.) How an application goes about his mapping will in large depend on the semantics of that application. In a hypothetical application which involves no or little data turnover, it would be appropriate to establish a one to one correspondence between that namespace and an Interspace counterpart made up of wrappers. In cases of extremely large databases it may be more appropriate to establish a mapping to a subset of the space, thus avoiding the overhead of replicating the entire object space inside the Interspace. Regardless of case, the IDs associated with a wrapperIU should never be reused by an application when mapping objects (unless they the mapping represents a new version of an object, this is the only case in which it is appropriate to reuse an ID.)
Wrappers are the vehicle by which external resources are incorporated into the Interspace. Some objects will directly reflect their structure in the Interspace while others will provide only stubs to represent themselves.
An example application of wrappers is demonstrated by the HTML document object in the Interspace system. The basic HTML document consists of a series of tagged pieces of text, the meaning, or semantics, of each section is encoded in that tag. For the Interspace system this means that the document object must be able to decompose the HTML document into its component objects. The division and their representation will forms give a feeling for the flexibility of the wrapper system.
One possible breakdown would be to design wrappers for each of the sectional components (i.e., title, body, etc.) and then combine them in the standard manner (i.e., object embedding) to form the complete document. Additionally the various the links in the documents would be transformed into first class wrapperIUs with all the functionality that implies. Images and sounds will be encapsulated and embedded to become, again, first class object with full IU functionality.
An even more interesting example comes from links to items, which can be reconstituted in object form inside the Interspace system, from the form in the external document. A good example of this kind of transformation is an equation in an HTML+ document. An HTML+ document contains a description of an equation in a form that can be used to recover the "real" equation. This real equation would then be used to make an instance of an Interspace equation IU. The equation IU would be both display itself in the document, but would also be able to be evaluated and otherwise manipulated because the form in the document is no longer only a shadow of the original object but is in fact a real object with all the functionality the author chose to put in it. This sort of translation is either impossible or very difficult in non-object systems like WWW, because their base description of the data they contain is modeled on textual documents not on objects (or even data structures.) Ultimately, it is the Interspace's ability to model objects (data) directly that is the source of the systems flexibility and power.
An alternate design for an HTML document wrapper IU is to encapsulate only the document itself and none of its subparts. In essence the document would treated as an atomic entity. This kind of wrapper allows the user to interact with the document and invoke operations of it, but does not allow for the internals of the object to be fully exploited. In this case linking could only occur at the level of the encapsulator itself, an image in the document would have no meaning to the Interspace system because the document object is essentially opaque to the system.
The above could even be extended to the level where all interaction with the object are completely external to the system, and the role of the system is only to invoke an external displayer (in some ways this is precisely the kind of split we see in WWW clients.)
Mixtures of functionality between the complete representation of a given object in Interspace to merely an invocation role are possible. This flexibility allows for the gradual introduction and integration of a new complex object type or system of types into the Interspace.