next up previous contents


We discuss now different approaches to transforming a single-user layering to a multiuser one.

One approach is to keep the exact same set of layers and add collaboration functionality to one or more of these layers. This approach is used in many existing architectures including Shared X, which extends the X window server, and Suite, which extends the view layer. However, it supports limited reuse of existing software since it requires changes to the layers that are made collaboration-aware. Moreover, all implementations of a layer must be changed even if they provide the same interface. It also supports limited modifiability in that a single-layer implements both the single-user and collaboration semantics. (These problems may be reduced, but not eliminated, if these layers are coded in an object-oriented programming language, since the changes may be localized in high-level classes and automatically inherited by unchanged lower-level classes.) Finally, it is not viable if the source code of the layer to be changed is not available.

Another approach is to put a pseudo-layer between two existing layers of the single-user architecture. To each of these two layers, the pseudo-layer provides an extension of the interface the other one provided. As a result, it accepts all of the input and output events sent to it by the layers below and above it, respectively. Depending on the nature of the interface between the two existing layers, the addition of the pseudo-layer may require recompiling and/or relinking of the existing layers. However, unlike other approaches, it does not require changes to the original layers. Moreover, it allows the same pseudo-layer to be added between multiple implementations of the two layers, as long as these implementations provide the same interface. It also supports increased modifiability since a pseudo-layer does not have to be changed in response to changes in the implementations of the original single-user layers. This approach is supported in XTV, which inserts a pseudo-layer between an X server and client, and COLA [TRM94] and DistView [PS94], which add pseudo-layers at higher-levels.

The pseudo-layer approach has two main drawbacks: First, all communication between the two layers of the original architecture must now pass through an extra layer, which may reside in a separate address space. For instance, in XTV, all communication between an X server and client must pass through a pseudo X server. Second, a pseudo-layer may need to duplicate the data structures and code of the original layers. For instance, an X pseudo-server that allows only certain windows to be shared must recreate the window tree hierarchy maintained by the X server.

Adding a pseudo-layer does not change the layering degree of the architecture, since the layer is not a ``real'' layer in that it does not transform its input or output. A pseudo-layer can be considered as logically belonging to the next lower layer, and should be replicated, threaded, or distributed with this layer.

Figure 9.5: Modifying a 1-user layer vs adding a new pseudo-layer.

Which levels of the architecture should be made collaboration-aware, that is, at which levels must collaboration awareness be added to existing layers or new pseudo-layers introduced? One approach is to localize these modules at a single level. Assuming this approach is used, we need to choose the collaboration-aware level.

There are several advantages of choosing a lower-level. First, a lower-level is typically common to a larger number of applications. gif For instance, the X window system is used by both Suite and non-Suite applications, while the Suite view layer is used only by the subset of X applications that are Suite applications. As a result, adding collaboration-awareness at a lower-level typically provides collaboration support for a larger number of applications, since it is available not only to direct clients of the layer but also clients of higher-level layers implemented on top of this layer.

Second, a lower-level layer can give users earlier feedback than higher-level layers. In general, there is a delay between the time information is received by a lower-level layer and the time it is transmitted to a higher-level layer. For instance, a widget layer may transmit edits to a form item to the higher-level layer only when the user completes the item. Hence, the lower-level a collaboration-aware layer is, the earlier it can distribute a user's edits to others and point out access and concurrency control violations.

Earlier feedback allows users to collaborate more synchronously and reduces the amount of work that may have to be undone. Finally, under this approach higher-level layers are not required to process interaction events from lower-level layers (see below), which makes them more modular and portable since they are dependent on handling fewer kinds of events from lower levels.

On the other hand, there are two important, related advantages of adding collaboration support at higher-levels. First, coupling, locking, access control, and other collaboration functions can operate on units that are more meaningful to the user/programmer. For instance, unlike a window layer, a view layer can separately lock the different views displayed in a window. Second, a higher collaboration-aware level can, if it is replicated, typically, provide more degrees of sharing among peers at that level. To explain why, we make the following two observations. The sharing of peer interactor objects implies the sharing of the next-level abstraction objects, assuming that abstractions are kept consistent with their interactors. However, the sharing of an abstraction does not imply sharing of its interactors, since the peer interactors may transform the shared abstraction in different ways and add different kinds of syntactic sugar. Thus, a collaboration-aware layer can allow (a) no sharing between peer abstractions, (b) sharing of peer abstractions without sharing of lower-level interactors, and (c) sharing of lower-level interactors if appropriate input events can be solicited from the lower-level layers. For instance, Suite can allow (a) no sharing between peer views, (b) sharing of peer views without sharing of the windows displaying them, and (c) sharing of peer windows by soliciting all X events. In contrast, a lower collaboration-aware level cannot allow sharing of higher-level abstractions without sharing of their interactors at this level.

In the higher-level case, sharing of lower-level interactors is achieved, at the cost of increasing the interaction awareness in the higher-level layer, that is, the awareness of interaction events of lower-level layers. For instance, to allow sharing of lower-level interactors such as widows, multiuser Suite is forced to handle several low-level X events such as window movement and resize events, which single-user Suite was unaware of.

We associate a collaboration architecture with an awareness degree, which is the level of the highest layer that is collaboration-aware. The value of this degree ranges from 1 in Team Workstation, which provides all collaboration support at the workstation level; to 5 in DistView, which requires the model layer to be collaboration-aware.

Since there are benefits of adding collaboration-awareness at both lower and upper levels, it is useful to consider an approach that partitions this awareness among multiple layers. Such an approach could offer the benefits of both the lower-level and higher-level approaches. In particular, it can offer logical collaboration units, flexible sharing, and low interaction awareness. However, unlike the localized approach, this approach would require providers of multiple modules to address collaboration, coordinate their activities, and often implement similar functionality (such as remote invocation) multiple times. This approach is offered in MMConf by making both the window and application layers collaboration-aware, and in Suite, by allowing both the view and application layers to be collaboration-aware. Figure 9.6 illustrates the various approaches to collaboration awareness.

Figure 9.6: Approaches to collaboration awareness.

next up previous contents

Prasun Dewan
Wed Mar 3 11:45:04 EST 1999