Summary

  • CES used Argus atomic actions, locks and version stacks to make participating document changes serializable, recoverable and undoable across failures.
  • Commit established a clean system state. It did not preserve authorial intention, guarantee prompt mutual awareness, settle ownership of an edit or prove that collaboration itself had succeeded.

The coauthor waiting behind a quiet lock

A writer stops typing to answer the telephone. The document node remains locked. Somewhere else, a coauthor is ready to work on that same passage.

This was not a decorative usability example in the 1985 paper on the Collaborative Editing System, or CES. It was a reason to invent a policy. The system’s “tickle lock” could be released after the holder had been idle and another author requested access. The waiting writer could proceed without an abandoned lock freezing the document indefinitely.

The mechanism solved a precise machine problem. It did not determine why the first writer paused, whose revision mattered more, whether the second writer understood the unfinished thought, or whether taking the lock would damage a relationship. Atomicity could regulate access to a node. It could not negotiate the social meaning of the interruption.

That gap is the most durable part of the experiment. Irene Greif, Robert Seliger and William Weihl studied how new atomic data abstractions behaved inside a real collaborative application written in Argus. Their system made strong guarantees about data while displaying, almost incidentally, how much of collaboration remained outside the transaction.

A document was not one indivisible object

CES represented a document as an outline and a collection of nodes. A primary author owned each node. The structure was replicated, while the node contents could be distributed. Different writers could work independently on different nodes; writers contesting the same node were serialized by a lock. Readers could accept a slightly stale copy rather than wait for every remote update.

This design did not promise the fluid character-by-character coauthoring now associated with online editors. Small editing commands ran as atomic actions while a writer retained a lock. The local writer saw typed characters immediately, but other screens were refreshed at intervals after those actions committed. A remote coauthor could therefore look at an older, internally valid view even though a newer change had committed elsewhere.

That distinction separates three claims often collapsed into one. Serializability says concurrent actions have an equivalent serial order. Recoverability says an action takes effect completely or aborts without a half-state. Awareness says people can see enough of one another’s current activity to coordinate. CES addressed the first two directly. Its display policy made clear that the third had its own latency and evidence.

The version stack remembered state, not motive

Argus helped CES recover after machine failure and offered atomic types whose operations participated in actions. CES added version stacks so an author could retrieve older states and undo a sequence longer than a single atomic action. Yet the paper describes an awkward edge: a user might know a change had committed while another machine, not yet informed of that decision, still displayed an earlier version.

The stack kept content. It did not keep an explanation of why a paragraph was changed, which alternative an author rejected, or whether a restored version was an act of correction or a new disagreement. A transaction log can say that one state followed another; authorial intention requires provenance, discussion and judgment that the data structure did not claim to supply.

The prototype’s performance also resisted a clean success story. With too little memory it was unusable. With enough memory it became usable but sluggish, and network access to stable storage could more than double access time. Those results matter because a correct collaboration tool that delays awareness changes human behaviour. Writers wait, work around the system, or infer absence from silence. Response time is not atomicity, but it helps determine whether atomicity is experienced as cooperation or obstruction.

Greif’s earlier work helps explain the boundary

Greif’s 1975 MIT dissertation argued that synchronization should be specified through orderings derivable within a system, not through an external global clock that may be impossible to realize. The dissertation did not design CES, and its partial-order model should not be retrofitted into a direct genealogy of every later groupware product. It does establish a recurring discipline: state only the ordering the mechanism can enforce.

CES followed that discipline. An atomic action could order and recover participating operations. It could not impose a total order on every human observation, nor could it turn “the latest committed version” into “the version all collaborators currently understand.” The latter claims would need additional communication.

Greif’s wider contribution also exceeded one implementation. ACM’s institutional history records her as a founder of computer-supported cooperative work, from a 1984 workshop through the first CSCW conference in 1986. That field-building role is best understood as creating a place to study both technical coordination and the people around it—not as proof that Greif alone invented groupware.

Credit belongs to the system around the subject

The paper’s credit boundary is explicit. Robert Seliger developed CES; he was the second author of the paper and the application supplied its three examples. William Weihl coauthored the analysis of atomic data types. Argus itself came from Barbara Liskov’s larger research programme and team. Greif is the right subject because the work sits at the junction of her synchronization research and her effort to establish CSCW, but she is not a substitute for those contributors.

The paper says CES’s basic structure and interface existed before Argus was selected. The application was not built merely to advertise a transaction language. Argus was chosen so researchers could prototype quickly, place a coauthoring system before real users and refine it from their response. That purpose makes the shortcomings valuable evidence rather than embarrassment.

Five boundaries, not one verdict

CES should not be judged by asking whether it “solved collaboration.” It separated five dimensions that contemporary systems still need to measure independently.

Data consistency asks whether document operations can be serialized. Failure recovery asks whether partial work can be removed or restored. Interaction response asks when an individual sees the result of a command. Collaboration awareness asks when others see who is doing what. Social coordination asks who may edit, how conflicts are discussed and which intention should govern.

An atomic commit can answer the first two. Careful interface and network design support the next two. The fifth requires human rules, explanation and legitimate authority. A system becomes dangerous when a green commit indicator is allowed to stand in for all five.

Sources