Functionality

There are several major functionality issues with the foregoing systems that I will enumerate here:

MVC Issues

MVC issues are discussed here in the functionality section rather than in the implementation section because the difficulties encountered are architectural, and they bleed through strongly to the functionality of the system, as described below.

Rendezvous and Weasel both combine the view and controller functions of the MVC paradigm. XTV and Chung’s infrastructure only marginally support MVC through their model/view separation in layers. This is because models are black boxes and cannot be queried, which is a required operation for pull MVC. Also, XTV and Chung’s infrastructure rely on counting messages from models in order to heuristically determine whether models are synchronized. This does not work with push MVC, where different notifications are sent to different views, depending on view interest. (See [Chu02] for a more complete description of the difficulties Chung’s infrastructure has in supporting MVC.) Only Clock has a separate controller mechanism, in the form of event handler functions that map between operations at the user-interface and application domain levels (see [PG99] and Figure 2.7). However, Clock uses the less efficient pull paradigm, enhanced with caching facilities as described above to mitigate some of the performance problems. A push approach would be more efficient, but it is difficult to implement with a constraint system based on method calls (such as Clock) rather than events.

Rendezvous advertises that the ALV paradigm provides better separation of mod- els and views than MVC, because links can map between the two, eliminating the

view’s knowledge of the model. Clock’s indirect call and constraint mechanisms ad- vertise similar separation via indirect communication. However, both systems tend to force model data to be structured like the user interface. This complicates imple- menting multiple, differing views of the same model, since the model cannot simulta- neously reflect the structures of radically different views. In general, any model/view dependencies tend to reduce the reusability of these components, which diminishes divergence possibilities available to participants.

Weasel implements a fairly traditional pull MVC paradigm, where view and con- troller are combined. The Rendezvous ALV paradigm is more like push MVC. Ren- dezvous and Weasel both modify models directly at a low level of abstraction, rather than at the level of application-domain operations. Operating on models at a low level of abstraction tends to complicate concurrency control on models (which may need several low-level operations to be performed atomically), and consequently forces user-interface and collaboration awareness into the model. This makes it difficult to reuse models in unanticipated ways. Low-level operations on models also imply a more detailed knowledge of models by views (or links, in the case of Rendezvous).

Unshareability of Local State

Rendezvous, Weasel, and Chung’s infrastructure2 allow view-local state. Ren- dezvous and Weasel provide no mechanisms for sharing this state. This means that any application using this mechanism to diverge cannot share all of its interaction with anyone else. For Chung’s infrastructure, whether local state can be shared or not depends on the layer at which logging takes place. If logging takes place at a higher abstraction layer than the local state, then that state cannot be shared unless 2_{... and maybe Clock, depending on whether ADTs can be represented below the client/server} divide, and if so, what the semantics of that would be.

low-level events describing changes to that state are passed to higher layers. For ex- ample, mouse cursors are not shareable in XTV unless the window system is told to send all cursor motion events, because otherwise the local state of the cursor position is entirely within the X server.

Invisibility to Participants of Divergence Parameters

Neither Rendezvous nor Weasel provides mechanisms for exposing to the users the various ways in which their views might be allowed to diverge. For Rendezvous, this would be difficult, because constraints link low-level variables that may not have meaning to the user. For Weasel, it might be more reasonable, since function pa- rameters can operate at a higher level of abstraction. However it is not clear that function parameters would always indicate a reasonable point of divergence, or how to indicate which parameters do and which don’t. Thus, for these systems, specifying divergence is mostly within the realm of the developer, not the participant. XTV, Chung’s infrastructure, and Clock do not support much in the way of divergence.

Non-determinism

XTV and Chung’s logging infrastructure are, in general, non-deterministic. They are implemented using heuristics that usually work, but are not guaranteed to do so. This is not a fault the infrastructure, as it is doing all it can to implement syn- chronous distributed collaboration using components not necessarily designed for this purpose. Nevertheless, non-determinism is a serious deficiency, and any collaborative infrastructure should be deterministic whenever possible.