The Two Spools of OSMIC
or,
Sometimes It's Easier to Keep It All

THE MODEL OF STORAGE

In OSMIC, data is logically saved in the server as two cumulative spools-- that is, Append-and-Read-Only files. 

             

Arriving data is appended to the Primedia file.  Specifically, since we are presently dealing only with text, the text string inserted by each insertion operation is appended to the primedia file.

A code for each edit operation is appended to the OPS file.  The code is defined in such a way as to permit replaying the operation; thus a code for an insertion operation refers to the specific text string which has been appended to the primedia file.

We intend that later primedia spools can receive audio samples, video frames, fax scanlines, and other countable data.  Indeed, the code for handling the elements of a primedia file should be identical, though elements may be different in different primedia files.

The server does not store versions.  Nothing stores versions.  Versions themselves are not saved, but regenerated as needed from these two files.

The server keeps the primedia and opcodes, and versions are built as needed in the client.  That's why the client is much bigger than the server.

A version is completely specified by its microversion number.  This fully specifies the ascending sequence of opcode numbers which lead up to it.

By beginning with the null document and numerically following the forking sequence of operations through the hypertime map that lead up to this microversion number, the microversion is rebuilt.  When a version forks, the process takes that turn on the map, like a model train.

Thus to regenerate a particular microversion, all that is needed is to perform the lexically successive operations from state zero to that desired microversion.  (By "lexically successive" I mean in numerical order, except where an alphabetical branch occurs.)

(We omit here the slightly more complex logic of enacting the transclusion operation.)
 

The protocol, designed by Ken'ichi Unnai, is designed to minimze network traffic and especially to keep the server as stateless as possible.

The server has three functions:

Function 1)  Receive an opcode from a client (with a string if it is an insertion op) and store it under the appropriate ascending opcode number (supplied by the client).

Function 2)  In response to an opcode number sent by the client, return the opcode (and the string for that opcode, if it is an insertion op).

Function 3)  In response to a request for a version, send the entire series of opcode numbers, in sequence, required to regenerate that version.  Then, upon receiving each opcode from the client again, perform function 2, sending out the corresponding opcode.

The reason the client des not generate the sequence of opcodes is that clients are expected to be dumb.
 
 

---

OSMIC is best seen in operation.  We suggest you try out the prototype. Return to main OSMIC page