Greg Kochanski

These objects are data storage combined with a daemon process that serves a set of virtual files and enforces constraints on the state of the object. These objects are the core of the Mesa message representation.

We expect that the use of network objects will allow the creation of distributed applications that operate efficiently over wide-area networks. Wide area networks, of course, have large irreducible network delays, due to the time it takes light to travel from computer to computer. We can safely predict that accessing data in California (from New Jersey) will not take less than 50ms, even if one assumes orders of magnitude improvement in processing speed and bandwidth. As other components of computer systems become faster, these speed-of-light delays will dominate system performance.

Inferno network objects can range from stateless servers (where the data storage is read-only) to persistent data objects whose main purpose is to store state information.

Some advantages of Inferno network objects come from the shift of some of the computing from the machine on which the application is running to the machine on which the object resides. One gains parallelisim as network objects are spread about. This extends the Inferno model from one where data is distributed, but processes largely live on one machine, to a model where computation is as distributed as the data.

Another part of the advantage comes about because, given intelligence associated with the data store, one can relax concurrency and locking requirements. Especially if collisions are rare (i.e., two applications rarely attempt to use the same network object simultaneously), it can be far more efficient to build a collision-detection and recovery function into the network object than to accept the network delays associated with controlling access to the object (e.g., locking).

This model differs from existing standard programming models. It does not assume rapid file access, as conventional UNIX-style programs implicitly do. It does not make the assumption of a single large central server that transaction processing approaches do. It may also be more applicable where one cannot or does not wish to unwind other operations when a transaction cannot be completed. It is loosely related to CORBA (http://www.omg.org), but lighter weight, with the role of the centralized object broker being played by the Inferno namespace operations.

The served files of a network object correspond to the visible functions in a conventional (e.g., C++) class interface. The underlying stored data corresponds to the class' memory. The daemon also enforces that the object always be in a valid state.

In the Mesa messaging platform, messages and documents are represented as sets of Inferno network objects. This allows us to make messages into real modifiable documents, rather than frozen snapshots of the sender's disk. Messaging then has the opportunity to become more of a dynamic collaboration tool. For instance, rather than passing a document back and forth as it is edited, the document is a message in the network, and all the authors can access it.

I have implemented a web-based version of this kind of collaboration tool, and have shown (over 80 versions of several documents, by three authors) that it can dramatically reduce editing turn-around time and improve communication among the authors. One does not lose hours or days waiting for the other authors to look at the document.

Network objects (and thus writeable messages) also allow on-demand media conversions to be implemented more easily, and seem to simplify the message handling, by bundling the concurrency control with the message.

Future research will involve understanding how best to convert documents into a "semantically local" form, where changes from multiple authors can be automatically merged with minimal probability of nonsense generation.

Inferno, more distributed computation, different concurrency assumptions.

• Won't know until most of what is outlined here is done.
• Much of what is described here is follow-on research.

• If people use it heavily, it *is* a new way of treating data.
• Comparable to the shift from relational DBMS to OODBMS, probably.

• Algorithms.
• "Means for dynamically generating sets of remote server processes", maybe.