A shared window system such as VConf [Lan86] and Rapport [Ens88] is like a shared object system except that it supports sharing of windows rather than sharing of arbitrary objects. It offers its clients the abstraction of a shared window, which is a single logical window physically replicated on the screens of all users of the application. The system allows a client to be completely unaware that it is interacting with multiple users-- the client is aware of only the logical window and receives input events from and sends output requests to this window. The shared window system is responsible for creating the physical replicas of this window and keeping them consistent.
Two main architectures have been used in shared window systems: the centralized and replicated architectures. Under the centralized architecture, a single, central client is created for the multiuser application, which receives input events from the workstations of all users and broadcasts output requests to all of them (Figure 8.10).
Figure: Shared Window System: Centralized Architecture. A single
process receives input from both users and broadcasts output to both of them.
Under the replicated architecture, a separate replica of the application is created on each workstation, which executes the application code and sends output to only the local user. To ensure that the different replicas remain synchronized, input from all workstations is sent to each replica and mechanisms are used to ensure that the replicas process inputs from different users in the same order (Figure 8.11).
Figure: Shared Window System: Replicated Architecture. Each replica receives
input events from both users in the same order and displays output to its local user.
Figure: A Client of a Shared Window System
Implementing the example user-interface:
The programmer would define a single application program, which would be responsible for creating and updating the two logical windows shown in Figure 8.1. The shared window system would be responsible for creating physical replicas of these windows on the screens of both users of the application and keeping them consistent.
Under the centralized approach, a single process would be created for the program (Figure 8.10) and under the replicated approach a replica would be created for each of the two users of the program (Figure 8.11). Like the Colab implementation, this implementation would be an approximation of the example user-interface because of limitations of shared windows systems discussed below.
There are several benefits of using shared window systems to develop multiuser applications. Unlike the previous tools, they support collaboration-transparent application programs.
Moreover, it is possible to create a shared window system by extending an existing single-user window system. Such a window system can be used to create multiuser interfaces to existing clients of the single-user window system. These clients would not only include direct clients of the window system but also indirect clients, that is, clients of the single-user tools built on top of the window system. For instance, a shared X window system can be used to create multiuser user-interfaces to not only direct clients of the X window system but also the clients of the large number of toolkits and user interface management systems developed on top of the window system. Finally, since they manage the shared data structures, they can provide concurrency control to ensure multiple users do not submit input to a shared window simultaneously.
However, these systems have been designed mainly to allow existing single-user applications to be shared in the WYSIWIS mode. As a result, they have several disadvantages that make them unsuitable tools for general multiuser applications. Since they do not know the structure of the data displayed by the windows,
the only concurrency control mechanism they can support is coarse-grained floor control,
which allows only one user (the user with the floor) to enter input at any time. Continuing with the example, a shared window system can either allow both users to make arbitrary concurrent changes to the displayed procedures or allow only one of them to edit a procedure at any one time. Moreover, they cannot allow sharing of data without also sharing of the associated screen images created for displaying these data.
For instance, they cannot allow users of the example application to share the procedures displayed in the edit windows without sharing the complete contents of the windows. Furthermore, like Colab, shared window systems do not support user-controlled transactions-- users immediately see the effects of commands invoked by others.
Finally, both the centralized and replicated shared window approaches have important drawbacks. The centralized architecture creates a central bottleneck that broadcasts potentially large amounts of output [Lan86]. The replicated architecture does not suffer from this performance problem since the output for a workstation is produced by a local workstation. (It does require the shared window system to broadcast user input but input data are, typically, small in size.) On the other hand, it executes semantic operations multiple times, once for each replica of the application. This is not always desirable since multiple invocations of a semantic operation may perform computationally expensive operations multiple times, attempt to read the same file simultaneously, attempt to write the same data to a file multiple times, access files that are not available at all workstations, and send a mail message multiple times [Lan86] [Lau90] [Cro90]. For instance, if the example application program mails a message whenever a module is fixed, the message will be sent by each replica created by the shared window system. Thus, in several situations, shared window systems either do not give the desired performance or desired semantics. These drawbacks also apply to the Colab system since a broadcast method can invoke semantic actions.