Conference PaperPDF Available

High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System.


Abstract and Figures

Jupiter is a multi-user, multimedia virtual world intended to support long-term remote collaboration. In particular, it supports shared documents, shared tools, and, optionally, live audio/video communication. Users who program can, with only moderate effort, create new kinds of shared tools using a high-level windowing toolkit; the toolkit provides transparent support for fully-shared widgets by default. This paper describes the low-level communications facilities used by the implementation of the toolkit to enable that support. The state of the Jupiter virtual world, including application code written by users, is stored and (for code) executed in a central server shared by all of the users. This architecture, along with our desire to support multiple client platforms and high-latency networks, led us to a design in which the server and clients communicate in terms of high-level widgets and user events. As in other groupware toolkits, we need a concttrrency-control algorithm to maintain common values for all instances of the shared widgets. Our algorithm is derived from a fully distributed, optimistic algorithm developed by Ellis and Gibbs [12]. Jupiter’s centralized architecture allows us to substantially simplify their algorithm. This combination of a centralized architecture and optimistic concurrency control gives us both easy serializability of concurrent update streams and fast response to user actions.
Content may be subject to copyright.
Proceedings of UIST ‘95 1/10
High-Latency, Low-Bandwidth Windowing
in the Jupiter Collaboration System
David A. Nichols, Pavel Curtis,
Michael Dixon, and John Lamping
Xerox PARC
3333 Coyote Hill Rd.
Palo Alto, CA 94304
+1 415 812 4452
Jupiter is a multi-user, multimedia virtual world intended to
support long-term remote collaboration. In particular, it sup-
ports shared documents, shared tools, and, optionally, live
audio/video communication. Users who program can, with
only moderate effort, create new kinds of shared tools using
a high-level windowing toolkit; the toolkit provides trans-
parent support for fully-shared widgets by default. This
paper describes the low-level communications facilities
used by the implementation of the toolkit to enable that sup-
The state of the Jupiter virtual world, including application
code written by users, is stored and (for code) executed in a
central server shared by all of the users. This architecture,
along with our desire to support multiple client platforms
and high-latency networks, led us to a design in which the
server and clients communicate in terms of high-level wid-
gets and user events.
As in other groupware toolkits, we need a concurrency-con-
trol algorithm to maintain common values for all instances
of the shared widgets. Our algorithm is derived from a fully
distributed, optimistic algorithm developed by Ellis and
Gibbs [12]. Jupiter’s centralized architecture allows us to
substantially simplify their algorithm. This combination of a
centralized architecture and optimistic concurrency control
gives us both easy serializability of concurrent update
streams and fast response to user actions.
The algorithm relies on operation transformations to x up
conicting messages. The best transformations are not
always obvious, though, and several conicting concerns
are involved in choosing them. We present our experience
with choosing transformations for our widget set, which
includes a text editor, a graphical drawing widget, and a
number of simpler widgets such as buttons and sliders.
UIMS, window toolkits, CSCW, groupware toolkits, opti-
mistic concurrency control.
Jupiter supports long-term collaboration by providing a
shared, persistent virtual world composed of network places
[7]. By mirroring some of the ways people use physical
places, network places provide a context in which
users can work individually or with other users, by mov-
ing between (virtual) places,
users can organize the materials they are working on and
the resources they are using by distributing them among
the places, and
other users, materials, and resources can be brought into
an activity at any time, immediately gaining access to the
full context of the activity.
In addition, the Jupiter world is intended to be highly cus-
tomizable by its users, so that they can adapt it to their needs
as readily as people adapt physical spaces. This includes
facilities for creating new places, connecting existing
places, moving objects among places, creating new
instances of generic objects, modifying the behavior of
existing objects, and creating completely new types of
generic objects. These last two capabilities involve writing
programs in Jupiter’s internal interpreted programming lan-
One of the key characteristics of Jupiter is that all objects
there are shared and persistent. This applies to the places
themselves, to the documents or other materials, and to the
tools. For example, the Whiteboard is a useful generic
object that provides a drawing surface with simple sketching
tools. As users come and go from the place containing the
whiteboard they may open it, see its contents, and edit them;
any number of users may be simultaneously viewing and
editing it. Even if all the users leave the place, log out of
Proceedings of UIST ‘95 2/10
Jupiter, and come back later, the whiteboard will retain the
drawing that was left on it.
Jupiter’s central server stores the state of virtual objects and
executes all of their associated program code. In contrast,
the client programs run by users on their local workstations
remain largely ignorant of this virtual-world model. Clients
simply manage their local input/output hardware of behalf
of the server and the user. In particular, clients create and
modify windows according to specications received from
the server, report user input events to the server, and (when
available) capture, transmit, receive, and display audio and
video data under user and server control [8].
This paper describes the low-level, client/server communi-
cations facilities used by the implementation of the window-
ing toolkit to support Jupiter’s pervasive sharing between
users. The Jupiter programmer’s view of the toolkit will be
described in a separate, forthcoming paper.
Jupiter user interactions are subject to two sources of signif-
icant response latency, which occasionally cause delays up
to a few seconds. First, the serialization of server actions can
introduce contention for execution resources. More gener-
ally, though, some users connect to the system through high-
latency communications paths, such as low-bandwidth dia-
lup lines and long-haul or congested Internet routes. We
developed the design presented here in response to these
specic sources of latency, but the solutions described
would be applicable to any situation with the potential for
unacceptable user-event response times.
The server and client communicate in terms of high-level
widgets, such as sliders and text editors1. Both client and
server keep track of widget state, and communicate high-
level state changes, instead of low-level user events and
graphics primitives. This high-level protocol means they
transmit less information, and less frequently, than if a more
traditional networked window system (such as the X win-
dow system [25]) were used. Because windows can be
shared between several users, we need a concurrency con-
trol algorithm to maintain consistency.
The concurrency control algorithms use by groupware sys-
tems for sharing can be classied as being pessimistic or
optimistic. Pessimistic algorithms require communication
with other sites or with a central coordinator before making
a change to data. This communication can be made apparent
to the user, as with a oor control policy, or left implicit,
where the user’s program does the communication behind
the scenes. Even in the latter case, the user must wait for a
round-trip to the other sites before any change is nalized.
1. We use “client” to refer to the Jupiter client, which is the pro-
gram that runs on the user’s machine and displays windows on that
machine’s display. Our “server” runs application programs, which
make requests of the client and respond to user events reported by
it. The X window system [25] uses these words in the opposite
sense; “clients” are applications, and the “server” is the program
that displays the windows.
Optimistic concurrency control, on the other hand, requires
no communication before applying changes locally. The
party making a change applies it immediately, then informs
the other parties of the action. If more than one participant
makes a change at the same time, a conict resolution algo-
rithm creates compensating changes to move everyone to
the same nal state.
Optimistic algorithms are well-suited for high-latency com-
munications channels since the results of a user’s actions
may be displayed without waiting for a communications
round-trip. For these reasons, we chose an optimistic algo-
rithm for Jupiter. The client always applies user changes
(such as moving a slider or typing new text) immediately,
without waiting for a server response, thereby providing
users with immediate feedback.
Another way of classifying concurrency control algorithms
is by whether they use a central coordinator or are fully dis-
tributed. Because Jupiter already had a central server main-
taining the persistent virtual world, it was natural for us to
use a centralized architecture.
The combination of these two choices turned out to simplify
our system design considerably. While there are example of
both centralized and distributed groupware systems using
pessimistic concurrency control, the systems using optimis-
tic algorithms are fully distributed. A distributed, optimistic
algorithm must be prepared to handle a change from any
participant at any time. Much of the complexity for these
algorithms comes from this requirement, and getting all the
cases right is very difcult.
Instead, Jupiter uses the optimistic protocol only for the
individual server-client links. To the server, each client
appears to be operating synchronously with respect to the
server’s actions. The server can thus use a simple change
propagation algorithm to keep all the clients updated and in
In the next section, we review related work. Sections 3 and 4
describe the toolkit’s design in more detail. In Sections 5
and 6, we describe the two-way optimistic algorithm, which
draws from previous work, then describe how it is used to
achieve n-way consistency. Section 7 discusses issues
related to choosing message transformations, a necessary
part of the optimistic algorithm we use.
The related work falls into two main categories, groupware
systems with their approaches to concurrency control, and
window systems that cope with low-bandwidth, high-
latency communication links.
A number of groupware systems provide either toolkits for
building shared applications, or specic shared applications
such as text or drawing editors. These include CoEx [20],
DistEdit [17], GroupDesign [16], GroupKit [24], the Grove
text editor [12], LIZA [14], MMConf [5], Rendezvous [21],
Suite [11], and Visual Obliq [3]. LIZA, Rendezvous, Suite
Proceedings of UIST ‘95 3/10
and Visual Obliq use a centralized coordinator, while CoEx,
DistEdit, GroupDesign, GroupKit, the Grove text editor, and
MMConf are distributed.
Of these, GroupDesign and Grove are the only systems to
use optimistic concurrency control, and they have decentral-
ized architectures. As discussed above, these algorithms are
made more complex by having to support full n-way repli-
cation. The Jupiter two-way algorithm is derived from the
dOPT algorithm used by Grove. This paper extends their
work by showing a simplied algorithm that takes advan-
tage of the centralized architecture, and discusses the prag-
matics of designing the message transformations required
by the algorithm.
Jupiter is similar to Visual Obliq in a different way. Both
systems use techniques from the FormsVBT system for
Modula-3 [4] and provide tools for rapid prototyping of
shared applications. Visual Obliq requires that the applica-
tion explicitly manage sharing, while Jupiter provides
shared widgets. Also, Visual Obliq is not optimized for low-
bandwidth or high-latency communications.
Another group of systems deal with low-bandwidth commu-
nications channels in single-user window systems. These
systems use two basic approaches to dealing with low-band-
width: compression and code-shipping.
Compression systems include Xremote, Low-bandwidth X
(LBX) [13], Higher bandwidth X (HBX) [9, 10], and vari-
ous commercial programs for providing remote access to
Microsoft Windows connections, such as CarbonCopy.
They try to reduce the bandwidth used while keeping the
same semantics for the network protocol. Although remark-
able compression ratios can be achieved (HBX gets a 20:1
compression ratio in some cases), they do not eliminate the
round trips caused by user interactions such as keystrokes
and mouse clicks.
Jupiter eliminates many round-trips by only sending mes-
sages for larger-scale widget value updates, not for individ-
ual low-level keyboard and mouse events. However, it
requires a trade-off from the application designer: Jupiter
applications must use the Jupiter toolkit, and are thus lim-
ited to the set of widgets it provides.
The other approach to coping with slow networks is to split
the application into two parts, and send the code for one part
to the user’s machine where it can have fast access to the
display and input devices. This is done by Sun Microsys-
tems’ NeWS [15] and HotJava [26] systems, and by Bell
Lab’s Blit terminals [22]. We call this code-shipping.
The code-shipping approach is in principle very powerful,
since it allows the application to customize the communica-
tions protocol to its particular needs. An application can
send most of its user interface to the other side, and only
communicate high-level events, such as “please run this
database transaction with these inputs.” The Sam text editor
[23] for the Blit is an example of such an application.
However, code-shipping forces the application designer to
write a distributed application. The program must be split
and a network protocol invented for it. While this is straight-
forward in some cases, the problems of distributed systems,
such as maintenance of replicated state, must be addressed
by the programmers of these system. In some systems, the
code shipped to the user interface engine must be written in
a different programming language from the application, fur-
ther complicating development.
Again, by trading off some generality, Jupiter is able to hide
these network problems from the application. The applica-
tion programmer sees a conventional toolkit interface, and
the protocols and remote code are handled by the system.
Jupiter is built on top of an unmodied instance of the
LambdaMOO server; all of the server-side facilities
described here are written in the MOO programming lan-
guage [6]. The server contains a database of all the informa-
tion in the Jupiter environment, as well as a MOO
interpreter. Windowing applications are written by Jupiter’s
users and run in this server.
The programming interface presented to an application
writer is very similar to that of the FormsVBT system [1, 4].
A window is described with an S-expression that species
the types of widgets present and a containment hierarchy for
laying them out. For example, Figure 1 shows the descrip-
tion of a window we use for editable documents in Jupiter,
and Figure 2 shows how that window appears to the user.
This window consists of a vertical stack of things (VBox),
the rst of which is a horizontal row (HBox) consisting of a
push-button named “help” containing the text “Help”, some
ller that serves to place the two buttons at either end of the
row, and another button named “quit” and displaying the
(Button %help (Text “Help”))
(Button %quit (Text (FGColor red) “Dismiss”)))
(TextEdit %contents (BGColor white)))
Figure 1: An example form for Jupiter. Figure 2
shows the resulting window.
Figure 2: A window created by the form in Figure 1.
Proceedings of UIST ‘95 4/10
text “Dismiss” drawn in red. Below this row is a thin black
line (Bar), and a text editor widget named “contents”.
The name on a widget is used by the application to manipu-
late the widget (e.g., change its value) and by the toolkit to
inform the application of any user interactions with the wid-
get. The name is also used to refer to the widget in the com-
munications protocol.
Table 1 shows a list of the widgets supported by Jupiter.
These are mostly the conventional set from other window-
ing toolkits. The TypeIn widget is for single line text entry.
The TextEdit widget is for editing larger (plain text) docu-
ments. The StrokeEdit widget is a graphical display and
interaction widget, similar to EZD [2] or Tk’s canvas widget
[18]. The VideoPane and AudioHighlight widgets provide
support for audio/video communications.
Each widget type exports a set of operations to the applica-
tion. For example, the TextList widget, which allows a user
to select from a list of text items, supports operations for
changing the list of items and for setting which item is cur-
rently selected. Widgets with small values, such as Booleans
and Numerics, support setting that value. Widgets with com-
plex value types, such as the TextEdit and StrokeEdit wid-
gets, supply operations for incremental update.
In addition, each widget type supplies a set of event notica-
tions, most of which are a result of user interactions. Buttons
notify the application when they have been activated by the
user. Numerics do so when the user chooses a new value for
them. The StrokeEdit widget has a number of user interac-
tion modes, allowing the user to click on existing strokes, or
add new ones. When any widget event occurs, a predeter-
mined application routine is invoked with information about
the event.
Layout widgets
HBox, VBox horizontal or vertical composition
Fill, Glue, Bar spacing between widgets
Rim, Border space around a widget subtree
Leaf widgets
Numeric a slider
StrokeEdit graphical display and interaction
Text output only
TextEdit full text editor
TextList list of text items to choose from
TypeIn single-line input
Typescript append-only with user input
VideoPane displays a digital video stream
Filter widgets, which decorate a widget subtree
AudioHighlight ashes a border around the subtree
when a user speaks
Boolean shows a visible on/off value
Button push once or momentary
Table 1: Widget types available in Jupiter
Jupiter applications are sharable, with the toolkit automati-
cally maintaining identical widget values for each partici-
pating user. Each change made by a user is reported to the
application and automatically propagated to the other users.
Jupiter’s users run the client on their local workstation. It
makes a TCP connection to the server, running on a central
machine. The client program is assumed to evolve slowly,
with users obtaining a new one primarily when major proto-
col changes occur. Currently, implementations for the client
exist for several Unix platforms, using the Tcl/Tk toolkit
[18], and for Microsoft Windows, using the native Windows
programming environment.
The client-server protocol for Jupiter largely parallels the
programmer’s interface; most calls by applications result in
messages to the client, and most client messages generate
event notications to the application. The protocol is
designed to use one-way messages, not requiring immediate
replies, whenever possible.
When a window is created, the server sends the S-expres-
sion describing the window to the client, which creates the
corresponding window.
After the window is created, updates to widget values can
originate from either the client or server. Updates to simple
widgets, such as Numerics and Booleans, include the entire
widget value. For user-originated changes, low-level mouse
and keystroke interactions are ltered out. For example, the
Numeric widget does not send intermediate values while the
slider is being moved, but waits until the mouse button is
released to send the nal widget value.
More complex widgets, such as TextEdits and StrokeEdits,
use incremental state update messages. For TextEdits, a gen-
eral “replace this region of text with this value” message
sufces. StrokeEdits use a more complex protocol, shown in
Table 2.
Both client and server maintain a full copy of each widget’s
value. The client copy allows user changes to be reected
immediately in the window, before they are processed by the
server. The server’s copy is used to coordinate updates gen-
erated by the various clients sharing the widget. In addition,
the server’s copy provides quick access for applications;
they do not incur round-trip delays for fetching the values of
widgets in order to do computations.
As mentioned earlier, optimistic concurrency control allows
clients to change widget values without having to wait for a
server interaction. If either the client or the server initiates a
change to a widget, the change is immediately applied
locally and a notication is sent to the other party. When
messages cross on the wire, each receiver xes up the
incoming message so that it makes sense relative to the
receiver’s current state. The algorithm we describe guaran-
tees that these xups will sufce, that the client and server
Proceedings of UIST ‘95 5/10
will always agree on the widget value when all messages
have been received and processed.
Unlike other groupware systems, Jupiter does not use the
synchronization protocol directly between the clients.
Instead, each client synchronizes with the server, the server
serializes all changes and echoes changes made by one cli-
ent to all others that are sharing the widget. This lets us
achieve n-way synchronization by running independent
two-party synchronization protocols on each client-server
Figure 3 shows an example of two messages for a single
TextEdit widget that cross. If the messages are not trans-
Server Operations
create stroke, delete stroke change the set of graphic
items being displayed
Table 2: Operations available on StrokeEdit widgets
move stroke move an existing stroke
set stroke attributes change color, etc. of an
existing stroke
set mode set a user interaction mode,
allowing local creation or
deletion of strokes
set creation attributes set attributes for strokes cre-
ated by the user
Client Operations
hit down, hit up report simple mouse hits of
existing strokes
sweep down, sweep drag,
sweep up
report strokes hit by a sweep
operation that potentially
passes through several
create stroke, delete stroke reports user-initiated cre-
ations and deletions
client server
del 4 del 2
Figure 3: An example of an update conict. The
client has deleted the fourth character, “D”, while the
server has deleted the second one, “B”. Without
concurrency control, the client and server wind up
with different nal values. The x is to have the
server transform the client’s message into “del 3” so
that both client and server get the same result.
formed on receipt, the client and server wind up with differ-
ent nal values for the widget. Since the client intended to
delete the “D” in the original string, its message must be
xed up to read “delete 3” when the server detects the con-
The general tool for handling conicting messages is a func-
tion, xform, that maps a pair of messages to the xed up ver-
sions. We write
xform(c, s) = {c’, s’}
where c and s are the original client and server messages.
The messages c’ and s’ must have the property that if the cli-
ent applies c followed by s’, and the server applies s fol-
lowed by c’, then the client and server will wind up in the
same nal state.
Of course, there are many possible functions that have this
property. For example, the function xform(c,s) = {delete
everything, delete everything} would satisfy our ordering
property, but would probably not satisfy many users! In gen-
eral, the transforms should try to nd some “reasonable”
way to combine the two operations into a nal effect. For
our delete example, this is easy to do:
xform(del x, del y) =
{del x-1, del y} if x > y
{del x, del y-1} if x < y
{no-op, no-op} if x = y
That is, we modify the later index in the document to
account for the earlier deletion. Other pairs of operations
present more difculties; Section 7 talks about the issues in
designing transformations in more detail.
In describing the full protocol, it is helpful to picture the
state space that the client and server pass through as they
process messages. Figure 4 shows an example. Each state is
labelled with the number of messages from the client and
server that have been processed to that point. For example,
3,0 2,1
3,1 2,2
3,2 2,3
client server
Figure 4: The state space the client and server
traverse while processing messages. Each node is
labelled with the number of client and server
messages processed when in that state. A conict
has occurred starting from the state 1,1.
Proceedings of UIST ‘95 6/10
if the client is in the state (2,3), it has generated and pro-
cessed two messages of its own, and has received and pro-
cessed three from the server.
As each message is processed, the client or server moves
down though the state space. If they process messages in the
same order (that is, there are no conicts), then they will
take the same path. If there is a conict, then the paths will
diverge, as shown in the diagram. The client and server
moved to the state (1,1) together by rst processing a client
message, and then a server message. At that point, the client
and server processed different messages, moving to the
states (2,1) and (1,2), respectively. They each received and
processed the other’s message using the xform function to
move to state (2,2). Then the server generated another mes-
sage, sending it and the client to (2,3).
The protocol labels each message with the state the sender
was in just before the message was generated. The concur-
rency-control algorithm uses these labels to detect conicts,
and the xform function to resolve them. The algorithm guar-
antees that, no matter how far the client and server diverge
in state space, when they do reach the same state, they will
have identical values for all their widgets.
The xform function takes a pair of client and server mes-
sages that were generated from the same starting state and
returns transformed messages that allow the client and
server to reach the same nal state. As long as the server and
client server
Figure 5: In this example, the server generates two
messages, s1 and s2, that conict with the client
message c. In order to process s2, the client must
compute c’, even though it will never execute it.
client server
s1’ c’
client diverge by only one step, we can use the xform func-
tion directly. If they diverge further, however, the situation
is more complex. Consider Figure5a. In this case, the client
has executed c and receives the conicting message s1 from
the server. It uses the xform function to compute s1’ to get to
the state (1,1). The server then generates message s2 from
the state (0,1), indicating that it still hasn’t processed c.
What should the client do? It can’t use xform(c,s2) because
c and s2 were not generated from the same starting state. For
example, if c is “del 4,” s1 is “del 1,” and s2 is “del 3,” then
the correct transform for s2 is “no-op,” but xform(c,s2) is
“del 3.”
The solution is depicted in Figure 5b. When the client com-
putes s1’, it must also remember c’, the other returned value
from xform. This represents a hypothetical message that the
client could have generated to move from the state (0,1) to
(1,1). When s2 arrives, the client can use c’ to compute
xform(c’,s2) = {c’,s2’}
It executes s2’ to get to the state (1,2). If the server has pro-
cessed the client’s message, it will be in the state (1,2) as
well. If not, its next message will originate from (0,3), so the
client saves c’ just in case.
We are now ready to examine the full algorithm, shown in
Figure 6. We describe it from the client’s perspective, but
the server’s actions are identical. The algorithm maintains
the invariant shown in Figure 7. The server was last known
to be in the state (x,y). Since then, the client has sent k mes-
int myMsgs = 0; /* number of messages generated */
int otherMsgs = 0; /* number of messages received */
queue outgoing = {};
Generate(op) {
apply op locally;
send(op, myMsgs, otherMsgs);
add (op, myMsgs) to outgoing;
myMsgs = myMsgs + 1;
Receive(msg) {
/* Discard acknowledged messages. */
for m in (outgoing) {
if (m.myMsgs < msg.otherMsgs)
remove m from outgoing
/* ASSERT msg.myMsgs == otherMsgs. */
for i in [1..length(outgoing)] {
/* Transform new message and the ones in
the queue. */
{msg, outgoing[i]} = xform(msg, outgoing[i]);
apply msg.op locally;
otherMsgs = otherMsgs + 1;
Figure 6: The algorithm used by client and server to
deal with conicting messages. The pair (myMsgs,
otherMsgs) corresponds to the state from Figure 4.
Proceedings of UIST ‘95 7/10
sages, leaving it in the state (x+k,y). These messages are
kept in the outgoing queue. In the code, myMsgs is x+k, and
otherMsgs is y.
Sending a message while maintaining this invariant is easy:
just apply the operation locally to move to (x+k+1, y), trans-
mit it to the server, and then append the message to the out-
going message queue.
For reception, we know that the next incoming server mes-
sage must originate from one of the states between (x, y) and
(x+k,y) inclusive; that is, the server will have processed
some arbitrary number of those k client messages. Assume
that it comes from state (x+i,y), taking the server to (x+i,
y+1). First, discard the saved messages that take us from (x,
y) to (x+i,y), as they are no longer needed. Next, run the
incoming message through the transformer with respect to
each of the saved messages. The nal result will be a mes-
sage that takes us from (x+k,y) to (x+k,y+1), which we
apply locally. While doing this, save the transformed ver-
sion of each saved message. When we are done, we have a
sequence of saved messages that takes us from the last
known server state, (x+i,y+1), to our current state, (x+k,
y+1). We have thus restored the invariant and are ready for
the next incoming message.
Some ne points
In our system, messages must be saved until they are
acknowledged by the other party, since they may be needed
in order to x up incoming messages. Normally, these
acknowledgments are piggy-backed on trafc going the
other way. However, it is possible for the trafc to a window
to be one-sided (e.g., for a status display window being peri-
odically updated). Therefore, each side must periodically
generate explicit acknowledgments (i.e. no-op messages) to
prevent the outgoing queues from growing forever.
client server
Figure 7: Whenever our algorithm is not processing a
message, the situation shown above holds (as seen
by the client). The server was last known to be in the
state (x,y). We are in the state (x+k,y) and have
saved all the messages necessary to get from (x,y)
to (x+k,y). The next server message must originate
from some state along this path.
An important consideration is the interaction of message
numbering with locking. The toolkit requires that applica-
tions hold a per-window lock whenever they are examining
or changing widget values for that window. If a message
arrives from a client while this lock is held, the message
cannot be processed until the lock is released.
However, messages must not be acknowledged before they
are processed. Figure 8 illustrates this problem. The client
sends a message to window B, which has been locked by
application code in the server. As a result, processing of that
message is deferred until the lock is released. Meanwhile,
the client sends a message to the unlocked window A, which
generates a reply that acknowledges both of the client’s
messages. While the window is locked, the application gen-
erates a message for B, which also claims to have been gen-
erated after both client messages. However, the client’s rst
message actually hasn’t been processed yet. The sequence
numbers will fool both client and server into assuming the
messages don’t conict when in fact they do.
This example shows that locks affecting any message must
delay processing of all messages with higher sequence num-
bers. To avoid unnecessary delays, message counters should
be maintained at a granularity at least as ne as the locking
granularity the applications use. Our system happens to use
window locking, so our counters are maintained on a per-
window basis. We could have used per-widget counters, but
that would have reduced the opportunity for piggy-backed
Comparison to dOPT
Our concurrency algorithm is similar to the dOPT algorithm
used in Grove. Our xform function corresponds to the trans-
formation matrix T in their system. In addition to the two
operations being transformed, T also requires two priorities
for tie-breaking. This is because T might be applied to oper-
ations for any two sites in the system. Because xform is
Figure 8: Sequence numbers must be assigned at a
grain at least as ne as the locking granularity of the
toolkit. Otherwise, an incoming message waiting for a
lock on one window might be incorrectly
acknowledged by the reply to a message for another
window window
Proceedings of UIST ‘95 8/10
always applied to operations between a client and the server,
it can have the tie-breaking rules built-in, simplifying the
specication of the transformations.
The dOPT algorithm also has code for saving messages that
arrived out of order from a site, then applying them when
earlier messages had been processed. Because we do not
multicast updates, we can assume a transport layer that
delivers messages in order, such as TCP, and omit the reor-
dering code.
Finally, Jupiter’s algorithm xes a problem with dOPT.
When sites diverge by more than one step in the state space,
dOPT does not transform saved messages when processing
incoming messages (the situation shown in Figure 5).
Unfortunately, simply transforming saved messages does
not work for the n-way case, since the next message can
come from a third site that is in an inconvenient message
state. Since we handle n-way consistency differently, this
problem does not arise in our algorithm.
The algorithm described in the previous section allows two
parties to maintain synchronized widget state. By using a
central coordinator, it is easy to extend it to synchronize any
number of parties sharing a widget. To do this, the line
“apply msg.op locally” from Figure 6 is implemented on the
server as shown in Figure 9. As a message arrives from a
client, it is sent to all the other clients as well as being
applied to the local copy of widget value.
Essentially, the optimistic algorithm hides the asynchrony of
the clients from the server. The pair-wise optimistic algo-
rithm makes each client appear to the server to be operating
completely synchronously; whenever a client generates a
change, it appears that the client has processed all server
messages sent so far. If all the clients are synchronous, then
the simple algorithm of echoing changes from one to the
others works.
It may be easier to think in terms of the two-party guaran-
tees. As long as the server sends to a client every change it
applies that the client did not generate, then the two-party
algorithm guarantees the client and server will have the
same value for the widgets at quiescence. Since each of the
clients’ values is equal to the server’s value, they must be
equal to each other as well.
/* apply “msg” received from “client” */
apply msg.op to local copy of widget;
for (c in client list for this window) {
if (c != client)
Send(c, msg);
Figure 9: The algorithm used by the server to
maintain consistency between clients. This code
replaces the line “apply msg.op locally” in Figure 6.
An important part of using the optimistic protocol is choos-
ing transformations for the pairs of widget operations.
While the transformation to use is obvious for some pairs,
conicting requirements in the system make other choices
more difcult. This section discusses these concerns, and
how we balanced them in Jupiter.
At rst, the combinatorics of the problem can seem over-
whelming. Jupiter supports 19 client and 24 server messages
that directly operate on individual widgets, yielding 456
potential pairs to consider. Fortunately, most of these combi-
nations are uninteresting. Messages can only be in conict if
they are trying to update the same widget, so any messages
from different widget types need not be transformed.
The messages for window creation and deletion could cause
conicts if window ids were reused, since one message
might refer to an old instance of a window, while another
referred to a new instance with the same id. If the server is
careful to avoid reusing window ids, we can avoid these
problems, and need only consider widget-specic messages.
By considering only conicts within a widget type, we are
left with 65 cases. Of these, 42 are from the StrokeEdit wid-
get, where a number of client messages report user selection
of strokes. These messages are similar enough to be consid-
ered at once, reducing the number of cases for StrokeEdits
to 18 and for all of Jupiter to 41.
To give a avor for how the transformations work, we show
a few examples. Table 3 shows some of the client and server
operations for several widgets, and Table 2 from earlier in
the paper gives the list for the StrokeEdit widget.
Simple widgets, like Numeric sliders and Booleans, have
small values that are always sent in their entirety. For these,
we designate one of server or client to be the “winner,” giv-
xform(SetValue(v1), SetValue(v2))
= {no-op, SetValue(v2)}
The “losing” message is simply discarded.
For TextLists, transformations for SetValue vs. Replace-
Items and Activate vs. ReplaceItems discard the user action.
Each of these client messages is returning the index in the
list of text of the currently selected item. However, the
application has changed this list, and most likely cannot
make sense of this obsolete index. In this case, we believe
that the user will usually be able to identify the problem and
recover; the application is less likely to be that smart.
Widget Client messages Server messages
Numeric SetValue SetValue
TextList SetValue SetValue
Activate ReplaceItems
TextEdit Replace Replace
Table 3: Messages dened for selected Jupiter
Proceedings of UIST ‘95 9/10
The Replace operation for TextEdits deletes a region of text
and inserts a string to replace it. For Replace vs. Replace,
the transformation produces a nal state that (a) has
removed all the text requested by either Replace, (b) has
inserted the text requested by each, sorted by the starting
points of the delete regions. We arbitrarily chose to put
server text rst if both try to insert at the same spot.
One interesting subcase occurs when one Replace inserts
text into the middle of the region of text being deleted by the
other. We choose to insert the text anyway, since we want to
preserve the user’s input if possible. This is true even if the
inserted text is coming from the server, since it may be text
another user typed that is being echoed to this window.
However, the transformed Replace in this case has to delete
two regions, the one before the inserted text, and one after.
There is no “delete disjoint regions” operation for TextEdits,
so we split the operation into two messages, with the second
one implicitly generated from a fractional state number. In
general, one has to be careful that a transformation doesn’t
produce new operations not in the original set dened for a
widget. This was the only time we had this problem, and
message splitting let us nesse the problem.
The StrokeEdit widget’s input modes cause particular prob-
lems in choosing transformations. For example, two of the
modes a StrokeEdit can be placed in allow users to draw
new lines (“line mode”) and to click with the mouse to gen-
erate reports about which strokes were hit (“hit mode”). If
an application switches a StrokeEdit from line mode to hit
mode, then it arguably doesn’t expect to receive notica-
tions of new lines created by the user. On the other hand, we
don’t want to discard the user’s effort, either. Currently, we
keep the strokes, but this decision comes under discussion
from time to time.
To summarize, the guidelines we tried to follow were:
The set of operations should be closed under the transfor-
mation rules.
Try not to discard user input.
Try to avoid confusing application code.
While we could not always satisfy all these at once, we were
generally happy with the compromises we were able to
The Jupiter window toolkit is client-platform independent
and provides fast response to low-level user interactions
even over low-bandwidth, high-latency communication
channels. It achieves these goals through the use of a high
level of abstraction on the wire: Jupiter clients and servers
communicate solely in terms of high-level widgets and user
To solve the distributed-state synchronization problems that
this design entails, Jupiter uses an optimistic algorithm with
widget-type-specic transformations to recover from server/
client conicts. Jupiter’s combination of a centralized archi-
tecture and optimistic concurrency control gives us the
advantages of both: easy serializability of concurrent update
streams and fast interactive response.
Our concurrency-control algorithm is a variant of one devel-
oped by Ellis and Gibbs for their Grove text editor. Our con-
tributions include
signicant simplication and improvement due to our
added assumption of an ordered, reliable communications
channel between exactly two participants,
a mechanism for doing full n-way sharing of widget val-
ues using the pair-wise algorithm, and
a discussion of some of the issues involved in designing
the associated transformation functions for pairs of con-
icting messages.
In addition to the authors, Ron Frederick and Bob Krivacic
have helped with the implementation of Jupiter. Early use of
the toolkit by Berry Kercheval gave us valuable insight into
its design. We are also grateful to Doug Terry and Ron Fred-
erick for reading early drafts of this paper, and to Lisa Alfke
for tracking down many papers for us on short notice.
[1] Gideon Avrahami, Kenneth P. Brooks, Marc H.
Brown, “A two-view approach to constructing user
interfaces,” Computer Graphics, 23(3), (July 1989),
pp. 137-146
[2] Joel Bartlett, “Don’t dget with widgets, draw!” Proc.
6th Annual X Technical Conference, Jan 1992, pp 117-
[3] Krishna Bharat and Marc H. Brown, “Building
Distributed, Multi-User Applications by Direct
Manipulation” Proceedings of the ACM Symposium on
User Interface and Software Technology (UIST ’94),
1994, pp 71-81
[4] Marc H. Brown and James R. Meehan, FormsVBT
Reference manual, available as part of ftp://
[5] Terrence Crowley, Paul Milazzo, Ellie Baker, Harry
Forsdick, and Raymond Tomlinson, “MMConf: an
infrastructure for building shared multimedia
applications” Proc. of the Conference on Computer-
Supported Cooperative Work (CSCW ’90), Oct. 1990,
pp 329-342
[6] Pavel Curtis, LambdaMOO Programmer’s Manual,
available as
[7] Pavel Curtis and David A. Nichols, “MUDs Grow Up:
Social Virtual Reality in the Real World,” Proceedings
of the 1994 IEEE Computer Conference, pp. 193--200,
January 1994. Also available as ftp://
Proceedings of UIST ‘95 10/10
[8] Pavel Curtis, Michael Dixon, Ron Frederick, and
David A. Nichols, “The Jupiter Audio/Video
Architecture: Secure Multimedia in Network Places,”
to appear in ACM Multimedia ’95.
[9] John Danskin, “Previewing PostScript over a
telephone in 3 seconds per page,” Proc. 9th Annual X
Technical Conference, Jan 1995, pp 23-40
[10] John Danskin, “Higher bandwidth X,” Proceedings
ACM Multimedia ’94, Oct. 1994, pp 89-96
[11] Prasun Dewan and Rajiv Choudhary, “Primitives for
programming multi-user interfaces,” Proceedings of
the ACM Symposium on User Interface and Software
Technology (UIST ’91), 1991, pp 69-78
[12] C. A. Ellis and S. J. Gibbs, “Concurrency control in
groupware systems,” Proc. 1989 ACM SIGMOD
International Conference on the Management of Data,
June 1989, pp 399-407
[13] Jim Fulton and Chris Kent Kantarjiev, “A report on
Low Bandwidth X (LBX)”, Proc. 7th Annual X
Technical Conference, Jan. 1993, p 251
[14] S. J. Gibbs, “LIZA: An extensible groupware toolkit”,
CHI ’89 Conference Proceedings, April 1989, pp 29-
[15] James Gosling, David S. H. Rosenthal, and Michelle J.
Arden, The NeWS Book, Springer-Verlag, 1989.
[16] Alain Karsenty and Michel Beaudouin-Lafon, “An
algorithm for distributed groupware applications,”
Proc. of the 13th International Conference on
Distributed Computing Systems (ICDCS), May 1993,
pp. 195-202
[17] Michael Knister and Atul Prakash, “Issues in the
design of a toolkit for supporting multiple group
editors,” Computing Systems 6(2), (Spring 1993),
pp. 135-166
[18] John K. Ousterhout, Tcl and the Tk Toolkit, Addison-
Wesley, 1994.
[19] Keith Packard, “Designing LBX,” Proc. of the 8th
Annual X Technical Conference, Jan. 1994, pp 121-133
[20] Dorab Patel and Scott D. Kalter, “A UNIX toolkit for
distributed synchronous collaborative applications,”
Computing Systems 6(2), (Spring 1993), pp 105-133
[21] John F. Patterson, Ralph D. Hill, and Steven L. Rohall,
“Rendezvous: an architecture for synchronous multi-
user applications,” Proc. of the Conference on
Computer-Supported Cooperative Work (CSCW ’90),
Oct. 1990, pp 317-328
[22] Rob Pike, “The Blit: a multiplexed graphics terminal,”
AT&T Bell Labs Tech. Journal, 63(8) (Oct 1984), pp
[23] Rob Pike, “The text editor Sam,” Software Practice
and Experience 17(11) (Nov 1987), pp 813-45.
[24] Mark Roseman and Saul Greenberg, “GroupKit: A
groupware toolkit for building real-time conferencing
applications,” Proc. of the Conference on Computer-
Supported Cooperative Work (CSCW ’92), Nov. 1992,
pp 43-50
[25] Robert. W. Scheier and James Gettys; with Jim
Flowers and David Rosenthal, X Window system: the
complete reference to Xlib, X protocol, ICCCM,
XLFD, Digital Press, 1992
[26] Sun Microsystems, Hot Java Home Page, available as
... Numerous approaches have been developed to overcome this problem in several ways. The most prevalent techniques are operational transformation (OT) [7], [8], [9] and conflict-free replicated data types (CRDTs) [10], [11], [12]. OT requires a centralized server and an active server connection to modify the replicated file collaboratively. ...
... Algorithms on replicated data structures are classified into two classes: operational transformation (OT) [7], [18], [8], [9] and conflict-free replicated data types (CRDTs) [10], [11], [12]. Many of the proposed approaches mainly support two operations: insert and delete. ...
... The presence of a central server is required in centralised algorithms to synchronise concurrent operations of users and get a global and unique order of execution. For example, COT (Sun and Sun, 2009), SOCT3 (Vidot et al., 2000), GOT , SOCT4 (Vidot et al., 2000), Jupiter (Nichols et al., 1995), Google Wave (Wang et al., 2010) and SCOP (Shen and Sun, 2002). In contrast, decentralised algorithm allows operations that are concurrent to be executed in any order such as OPTIC (Imine, 2009), ABTS (Shao et al., 2009), SDT , GOTO (Sun and Ellis, 1998), adOPTed (Ressel et al., 1996), SOCT2 (Suleiman et al., 1998), MOT2 (Cart and Ferrié, 2007) and TIBOT . ...
... Google Wave OT algorithm is basically based on Jupiter algorithm (Jupiter System) [53]. In Google Wave OT, the client need to wait for acknowledgement from the server before sending more operations. ...
Collaborative Editing (CE) has long captured the attention of Computer-supported- cooperative work (CSCW) researchers. Early researches about CE (in the 1990s and the early 2000) focused on describing different characteristics of CE based on interviewing people who had participated in some CE projects. Some recent researches about CE started analyzing the logs of CE activities to study how people edit together with support of modern CE tools such as Git version control systems and Google Docs. From the general view point, the process of CE is the continuous synchronization of ‘multiple, parallel streams of activity’ of collaborators. If the synchronization takes place less often, for example the development of a software project based on Git version control system, it is considered as ‘asynchronous’ work mode. And if the synchronization takes place within a small interval, for example editing a shared document in ShareLaTex, it is considered as ‘synchronous’ work mode. The longer the divergence is, more conflicts are likely to happen during the synchronization. Resolving conflicts is costly, especially after a long period of divergence. Understanding how often conflicts happen and how do user resolve conflict in real CE projects is important to ensure good performance and user experience in collaborative editing. In the first part of this thesis, we borrow the collaboration traces of four large open source projects in Git version control system to conduct our analysis. We analyze different types of textual conflicts that arise during the development and how developers resolve these types of conflict. In particular regarding ‘adjacent-lines conflicts’, we found that users mostly resolve them by applying changes from both sites. Besides, we also analyze how often users use ‘roll-back to previous version’ as a way to resolve merge conflict. The process of CE based on online collaborative editor is more specific. It can be split into several ‘sessions’ of editing which are performed by a single author or several authors. They are denoted as ‘single-authored session’ and ‘co-authored session’ respectively. This fragmentation process requires a predefined ‘interval’ or ‘maximum time gap’ which is not yet well defined in previous studies. In the second part of this thesis, we analyze the logs of CE works of students of an Engineering School using ShareLaTeX which were collected and anonymized for privacy purpose. By examining different ‘maximum time gaps’ from 30 seconds to 15 minutes on the logs we found that we can determinate a suitable ‘maximum time gap’ to split CE activities into sessions by evaluating the distribution of the ‘external-distance’. Besides, we analysed the editing activities inside each ‘co-author sessions’. We borrow a [30 seconds, 10 characters] time- position window to examine these ‘potential conflict’ cases. The result shows that people rarely edit closely in both time-position. However, conflicts are more likely to happen in these cases.
O ESPIM, abreviação de “Experience Sampling and Programmed Intervention Method” em inglês, é uma metodologia que integra os conceitos do método “Experience Sampling Method”' (ESM) e das áreas de Computação Ubíqua e “'End-User Development”' (EUD). Essa metodologia combina a coleta estruturada de autorrelatos em ambientes naturais com a aplicação programada de intervenções por meio de smartphones, utilizando várias formas de mídia. Para criar e implementar programas de intervenção por meio do ESPIM, os profissionais especialistas utilizam uma plataforma que inclui software web para a autoria dos programas, programas esses que são acessados remotamente pelos usuários-alvo por meio de um aplicativo Android. No entanto, um dos desafios enfrentados pelos profissionais que utilizam o ESPIM é a ausência de suporte para a edição colaborativa síncrona dos programas de intervenção. Isso é especialmente relevante devido à crescente demanda por ambientes de autoria que permitam a colaboração em tempo real entre autores. As soluções apresentadas neste trabalho podem guiar desenvolvedores que desejem transformar seus editores em sistemas que promovem o trabalho em equipe com edição síncrona.
Collaborative applications are becoming more prevalent for a variety of reasons, most important of which is the increased interest in remote work. In addition to adapting the business processes to a remote setting, designers of collaborative software have to decide on how their software can be used collaboratively. This paper discusses the two main technologies used to enable network-based real- or near-real-time collaborative software, namely Operational Transformation and Conflict-free Replicated Data Types. Recent developments in each technology are discussed, as well as a brief overview of their theoretical underpinnings.KeywordsOperational transformationConflict-free replicated data typeEventual consistencyOTCRDTCollaborative text editingStrong eventual consistency
Conflict-Free Replicated Data Types (CRDTs) support decentralized collaborative editing of shared data, enabling peer-to-peer sharing and flexible branching and merging workflows. While there is extensive work on CRDTs for plain text, much less is known about CRDTs for rich text with formatting. No algorithms have been published, and existing open-source implementations do not always preserve user intent. In this paper, we describe a model of intent preservation in rich text editing, developed through a series of concurrent editing scenarios. We then describe Peritext, a CRDT algorithm for rich text that satisfies the criteria of our model. The key idea is to store formatting spans alongside the plaintext character sequence, linked to a stable identifier for the first and last character of each span, and then to derive the final formatted text from these spans in a deterministic way that ensures concurrent operations commute. We have prototyped our algorithm in TypeScript, validated it using randomized property-based testing, and integrated it with an editor UI. We also prove that our algorithm ensures convergence, and demonstrate its causality preservation and intention preservation properties.
Modern cooperative software systems involve multiple concurrent users undertaking a common task in a real-time distributed environment, such as editing a shared text document. Maintaining data consistency, transaction causality, and replication convergence in such an environment, while providing fast client responsiveness, is a substantial challenge for classical distributed computing techniques. Operational transformation (OT) is a class of concurrency algorithms and data models that supports these functionalities, which has drawn significant research attention in the past decade. In this review, we discuss the basic components of operational transformation models, the algorithms involved, and their actual implementations in real-world networked systems. We compare several existing OT control algorithms, the transformation functions and properties supported by each of the algorithms, and the trade-offs that are made with respect to each one. The data and operational models used in OT are well suited for high- latency environments such as the Internet, making them more frequently used in modern web services. Although many different OT control algorithms exist, choosing the most effective one often depends on the particular operations that an application must support.
Full-text available
Replicated tree data structures are extensively used in collaborative applications and distributed file systems, where clients often perform move operations. Local move operations at different replicas may be safe. However, remote move operations may not be safe. When clients perform arbitrary move operations concurrently on different replicas, it could result in various bugs, making this operation challenging to implement. Previous work has revealed bugs such as data duplication and cycling in replicated trees. In this paper, we present an efficient algorithm to perform move operations on the distributed replicated tree while ensuring eventual consistency. The proposed technique is primarily concerned with resolving conflicts efficiently, requires no interaction between replicas, and works well with network partitions. We use the last write win semantics for conflict resolution based on globally unique timestamps of operations. The proposed solution requires only one compensation operation to avoid cycles being formed when move operations are applied. The proposed approach achieves an effective speedup of 68.19$\times$ over the state-of-the-art approach in a geo-replicated setting on Microsoft Azure standard instances at three different continents.
Conference Paper
Full-text available
Rendezvous is an architecture for creating synchronous multi-user applications. It consists of two parts: a run-time architecture for managing the multi-user session and a start-up architecture for managing the network connectivity. The run-time architecture is based on a User Interface Management System called MEL, which is a language extension to Common Lisp providing support for graphics operations, object-oriented programming, and constraints. Constraints are used to manage three dimensions of sharing: sharing of underlying information, sharing of views, and sharing of access. The start-up architecture decouples invoking and joining an application so that not all users need be known when the application is started. At present, the run-time architecture is completed and running test applications. As a first test of the complete Rendezvous architecture, we will implement a multi-user card game by the end of the summer.
Conference Paper
Full-text available
This paper presents our approach to the design of groupware toolkits for real-time work, and how the design is instantiated in our toolkit, GROUPKIT. The design is based on both the technical underpinnings necessary for real-time groupware, and on user-centered features identified by existing CSCW human factors work. We also present three strategies for building GROUPKIT's components. First, an extendible, object-oriented run-time architecture supports managing distributed processes and the communication between them. Second, transparent overlays offer a convenient method for adding general components to various groupware applications, for example supporting gestures via multiple cursors and annotation via sketching. Third, open protocols allow the groupware designer to create a wide range of interface and interaction policies, accommodating group differences in areas such as conference registration and floor control.
This book is an introduction to NeWS: the Networked, Extensible, Window System from Sun Microsystems. It is oriented towards people who have a basic knowledge of programming and window systems who would like to understand more about window systems in general and NeWS in particular. A significant portion of the book is devoted to an overview and history of window systems. While there is enough detail here to allow readers to write simple NeWS applications, the NeWS Reference Manual [SUN87a] should be consulted for a more complete treatment. This book was written to refer to the NeWS 1. 1 product, available from Sun and also available from several non-Sun suppliers. Shortly after this book is published, Sun will be releasing the next version of NeW- the Xll/NeWS merged window system. Chapter 10 is dedicated to an overview of that product, but Xll/NeWS deserves a book of its own. All the code examples in this book have been tested on both NeWS and the Xll/NeWS merge. Should there be another edition of this book, we will discuss some of the new development being done in the user interface tool­ kit area on NeWS. Significantly, the NeWS Development Environment (NDE) is now being developed at Sun; NDE promises to eclipse existing user interface toolkit designs and window programming environments.
Software for supporting groups of cooperating users — groupware — raises a number of new issues in user interface design. This paper gives a definition of groupware and presents a model of group tools based on active objects. The model has been applied to the design and implementation of an extensible groupware toolkit known as LIZA. The paper describes the architecture of LIZA. Examples of group tools running under LIZA are used to illustrate some of the problems in the design of multi-user interfaces.
Conference Paper
Network bandwidth has always been a key issue for multimedia protocols. Many potential users of networked multimedia protocols will continue to have low bandwidth network connections for some time: copper wire ISDN, infra-red, cellular modems, etc.. Compression provides potential relief for users of slow networks by increasing effective bandwidth. Higher Bandwidth X (HBX) introduces a new technique, based on arithmetic coding and statistical modeling, for compressing structured data. Applied to the X networked graphics protocol, this technique yields 6.3:1 compression across a representative set of traces, performing twice as well as the popular LZW-based Xremote compression protocol. HBX's coding techniques are generally applicable to the graphics and imaging subset of multimedia protocols. Future work will determine whether HBX's coding techniques can be applied to audio and video streams as well.
Conference Paper
Groupware systems are computer-based systems that support two or more users engaged in a common task, and that provide an interface to a shared environment. These systems frequently require fine-granularity sharing of data and fast response times. This paper distinguishes real-time groupware systems from other multi-user systems and discusses their concurrency control requirements. An algorithm for concurrency control in real-time groupware systems is then presented. The advantages of this algorithm are its simplicity of use and its responsiveness: users can operate directly on the data without obtaining locks. The algorithm must know some semantics of the operations. However the algorithm's overall structure is independent of the semantic information, allowing the algorithm to be adapted to many situations. An example application of the algorithm to group text editing is given, along with a sketch of its proof of correctness in this particular case. We note that the behavior desired in many of these systems is non-serializable.
Conference Paper
This paper introduces TeamWorkStation (TWS), a new desktop real-time shared workspace characterized by reduced cognitive seams. TWS integrates two existing kinds of individual workspaces, computers and desktops, to create a virtual shared workspace. ...