19
At the other extreme are systems that fully replicate all application data. This can en-
hance performance, since the local application has all information available locally, without
need to have recourse to the network, greatly reducing the effects of load issues and net-
work delays. However, in any pessimistic concurrency model, updates to that local state will
have to be controlled by some global interaction (usually a lock) so that the different local
states evolve in a consistent way. Optimistic concurrency control, and especially divergence,
come into their own when combined with fully-replicated architectures, since the freedom
from global synchronization tasks can pay direct benefits in response time and flexibility.
Most WYSIWIS applications fully replicate the data being edited so that response time will be
fast enough, and use complex concurrency protocols to ensure that the illusion of a single
edited object can be maintained. Much of the burden of distributed systems design is the
prevention of divergence between sites. Collaboration support is a realm where that burden
can be lifted and replaced with (hopefully) simpler mechanisms for securing eventual agree-
ment.
1.6 Generalized undo
Once an architecture is in place for implementing a distributed editor at all, then the
problems really begin. Now there is a group of human beings collaborating with each other
via a new medium, without the implicit restrictions of face-to-face interaction that normally
provide informal concurrency control. For example, no face-to-face editing scenario, no mat-
ter how collaborative or informal, will involve two authors simultaneously trying to change
the same word. While allowing such tight interaction may offer convenience, it also presents
a ground for conflict. Exacerbating these problems is the fact that the informal and uncon-
scious social cues and protocols that control such interaction are absent during computer-
only collaboration.
At the other extreme are systems that fully replicate all application data. This can en-
hance performance, since the local application has all information available locally, without
need to have recourse to the network, greatly reducing the effects of load issues and net-
work delays. However, in any pessimistic concurrency model, updates to that local state will
have to be controlled by some global interaction (usually a lock) so that the different local
states evolve in a consistent way. Optimistic concurrency control, and especially divergence,
come into their own when combined with fully-replicated architectures, since the freedom
from global synchronization tasks can pay direct benefits in response time and flexibility.
Most WYSIWIS applications fully replicate the data being edited so that response time will be
fast enough, and use complex concurrency protocols to ensure that the illusion of a single
edited object can be maintained. Much of the burden of distributed systems design is the
prevention of divergence between sites. Collaboration support is a realm where that burden
can be lifted and replaced with (hopefully) simpler mechanisms for securing eventual agree-
ment.
1.6 Generalized undo
Once an architecture is in place for implementing a distributed editor at all, then the
problems really begin. Now there is a group of human beings collaborating with each other
via a new medium, without the implicit restrictions of face-to-face interaction that normally
provide informal concurrency control. For example, no face-to-face editing scenario, no mat-
ter how collaborative or informal, will involve two authors simultaneously trying to change
the same word. While allowing such tight interaction may offer convenience, it also presents
a ground for conflict. Exacerbating these problems is the fact that the informal and uncon-
scious social cues and protocols that control such interaction are absent during computer-
only collaboration.
