Reasoning behind the OSMIC proposal:
MODELS OF TIME,
BACKTRACK AND GROUPWARE

THE ISSUES

Time, backtrack and groupware are very general problems.  We may think of these issues as

1) ways to think about time; and being gods, how best to define it;

3) models of versioning (especially version states available, past and future);

2) the different undo options to make available;

4) the issues of file locking-- who has the right to do what to which, how and when.

The OSMIC prototype software is intended to help us experiment with, and think about, all of these.

In what we may call the "naive model of time", time flows in one direction only.  The user only wants "the latest" version, and access to previous versions is unimportant.

Similarly, in current groupware models, versions must be "checked in" and "checked out", and all users inherit the latest changes on a document.

This is naive because there are many reasons you may want to use previous versions, or branch from previous versions.

(I am told that the experience among users of Lotus Notes is that different versions do not need to be resolved; users generally find they only need to understand their differences.).

These naive models of time and versioning generate two popular models: circular flip-flop undo, and linear sequential undo.

Windows and the Macintosh both have a backtrack system we may call simple flip-flop undo.  The "undo" key, ctrl-z (in Windows) or cmd-z (on the Mac) undoes ONE previous operation.  Repeating the process takes it back to the current state.
  FLIP-FLOP UNDO

Actually, for completeness we should add one more state.  If the user chooses to discard previous work and go back to a saved version ("revert" on the Macintosh), this allows one previous state to be accessed, usually a much earlier state.

FLIP-FLOP UNDO with reversion



This of course loses both the current and previous state.

The other model of time and undo allows more states, but still has a destructive model, losing different versions depending on the user's choice.

Here we need to represent the sequence of states of a document.  Beginning with an empty state S0, the user applies a series of editing operations



As in flip-flop undo, the user can go back to the previous operation--



However, in linear undo it is possible to continue to undo a sequence of previous operations, undoing them backward one at a time:
 

 
This is not normally possible with Windows or Macintosh.  However, it is used in some Unix text editors.

In some of these, it is possible to go forward again, meaning that the sequence of operations has not been not lost, only tentatively deleted.



It is not until the user makes a DIFFERENT change that the forward sequence of changes is lost. Consider the previously shown backtrack to state S5.



If the user now chooses (at state S5) to make a different change, then S6, S7, S8, S9 are lost forever.



However, it does not have to be that way.  The previous work (states S6, S7, s8, s9) do not have to be lost.  There is a good case for preserving all possible states of a branching series of edit operations.  That is what OSMIC demonstrates.
 

These issues also affect the ways people work together.  If we apply these naive models of time to software (or even text) which is being developed by groups of people, similar problems arise.

The most common approach is "file locking", where one user checks out a file and may change it.  This prevents two people from making contradictory changes on the file at the same time (in which case whoever presses "save" first wins).

However, this generally forces everyone to accept the work that others have previously done in the sequence, and cuts off the option of returning to an earlier state.

More importantly, it prevents working in parallel.  It also does not achieve the goal of allowing people to make different kinds of changes on the same material which may contradict each other at first, but which may later be reconciled-- in other words, working separately in parallel, as we should be able to do.

"Undo", destructive backtrack and file locking aren't the only alternatives.  We have a demo showing how any version in a network of versions-- a graph structure of versions-- can be easily changed, with all changes being kept track of.

In the model of time implemented in OSMIC, time is a graph structure and all previous states may be re-entered.  Furthermore, the contents of the different versions may be combined (through the "transclude" operation).

In the current prototype, you may go to any microversion of a branching document. 

Each separate change creates a new microversion.  (For convenience, we number the change and the resulting state identically: change 2 creates state 2.  A branch is given a letter, after which new integers begin with 1 again; thus change 2a4 creates state 2a4.  Unfortunately, you cannot at present give more convenient names to the microversions.)

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