Imagine two users, geographically dispersed, responsible for collaboratively testing a module and fixing the bugs.
Figure: A multiuser user-interface allowing two users to collaboratively edit and test a module.
They use their workstations, which are connected by a network, to interact with a distributed application that supports their collaborative task. Figure 8.1 shows the windows created by the application on the workstations of the two users. The top pair of windows in the figure is created on the workstation of user A while the bottom pair is created on the workstation of user B. The application displays in ``edit windows'' created on both workstations (Figure 8.1, upper and lower right windows) the module to be tested. It allows either user to select one or more procedures for testing and underlines in ``test windows'' (Figure 8.1, upper and lower left windows) the parts of these procedures that are not covered by the test data.
The test windows display identical images--if one of the users, for instance, scrolls the window, both windows are scrolled.
As a result, the users can collaboratively browse through these windows.
The edit windows, however, can display different images but display a common semantic state, that is, display the same set of procedures. As a result, the two users can independently browse through and modify the procedures displayed in their windows. These procedures are divided into private procedures, which can be modified by only one of these users, and shared procedures, which can be modified by both users. The application allows both users to modify the procedures they are authorized to edit. It broadcasts changes to a shared procedure as soon they are made and changes to private procedures only when they are committed. It provides concurrency control to ensure users do not simultaneously modify a shared procedure. It also provides users with a query language that allows them to determine which procedures are completely covered by test data. The two users carry out several iterations of collaboratively testing and fixing the module until they are satisfied.
This example illustrates the nature of multiuser applications-- applications that interact with multiple users, possibly geographically dispersed. It also illustrates the power of such applications-- it allows users to collaboratively carry out a complex task without having to leave their office or lose access to their workstations. Multiuser applications such this one have the potential of automating a significant amount of cooperative work carried out at current organizations [Dem87]. As a result, several experimental multiuser applications have been implemented recently including the Colab [Stef87] and GROVE [Ell90] outline editors, the RTCAL appointment system [Sar85], the CES [Gre86], Quilt [Fis88], and PREP [Neu90] co-authoring systems, the MACE graphics editor [New91a], the ICICLE code inspector [Bro90], a cooperative air-traffic control system [Ben92], the EXPRES system for collaborative creation, submission, and review of research proposals [Ols90], and the FLECSE collaborative software development environment [Dew93c].
The example also illustrates the difficulty in implementing a multiuser application. Like a single-user application, a multiuser application must perform computation tasks such as testing a module for coverage and interaction tasks such as processing input commands and displaying results. In addition, it must efficiently and flexibly carry out several collaboration tasks such as dynamically making and breaking connections with possibly remote users, multiplexing input from and demultiplexing output to multiple users, informing users of input entered by other users, helping users coordinate their interaction, and providing concurrency and access control [Sar85] [Ell90]. For this reason, few multiuser applications have been developed so far despite the tremendous potential of these applications. Moreover, most of the projects that have implemented these applications from scratch have, typically, been multi-year, multi-person projects.
Today, however, multiuser applications do not have to be implemented from scratch,
since a variety of tools exist that support the implementation of their user-interfaces.
These tools can be classified into eight main categories:
In this paper, we motivate and describe the main concepts behind the design of these tools, point out the similarities and differences among the approaches implemented by them, outline the kind of multiuser user interfaces they have been designed to support, and discuss the benefits and drawbacks of each of these approaches. We evaluate each of these tools based on three main criteria:
In the next section, we give informal definitions of concepts used to describe these tools. We then discuss each of these tools in a separate section. In each of these sections, we illustrate the working and capabilities of the tool by considering how it could be used to implement the example user interface above. We first describe traditional database systems and then, in each of the subsequent sections, describe a tool that overcomes some of the limitations of the tool described in the previous section. However, the reader should not conclude that the tools are presented in order of superiority since a tool often overcomes limitations of a previous tool by sacrificing some of the advantages of the latter. Finally, we present conclusions and directions for future work.
A brief version of this discussion is given in [Dew92], which describes multiuser Suite, a multiuser tool developed by the author, and compares it with other multiuser tools to highlight its unique features. This paper is also related to a recent paper by Ellis et al [Ell90], which surveys the area of multiuser applications, describing the important issues raised by these applications and approaches to resolving them. Our paper complements this work by surveying the related area of multiuser tools. Furthermore, it complements the companion paper on multiuser applications by Olson et al [Ols93], which addresses the functionality of multiuser applications but not their implementation. Finally, it is important to note that several social issues must be resolved before multiuser applications are widely used. This paper does not address these issues and concentrates only on the technical barriers to implementing them.