A UIMS separates semantic values from their screen representations. It is possible to use this separation in a multiuser UIMS to provide high-level abstractions for supporting sharing of both semantic values and their screen representations, as illustrated by the work on Rendezvous [Pat90] [Pat91]. Like Colab, Rendezvous assumes that the state of a multiuser application is encapsulated in objects and supports sharing of these objects.
In addition, it offers a constraint system, which can be used to keep related objects consistent. (Unlike a distributed constraint system, the Rendezvous constraint system relates data stored withing a single process.) Rendezvous also allows programmers to define rules, which can modify object state and are fired in response to input and other events. Rules can be associated with guards, which determine the conditions under which they fire.
Rendezvous distinguishes between abstract objects and view objects, which correspond to Smalltalk models and views, [Kra88] respectively. The former define semantic data while the latter define how these data are viewed and manipulated by users (Figure 8.14). Rendezvous supports three degrees of sharing: i) semantic sharing: sharing of abstract objects, ii) image sharing: sharing of view objects, and iii) complete sharing: sharing of views and access rights to these views. An abstract object is shared among a group of users by creating a view object for each of these users and defining constraints that keep the abstract object consistent with its view objects. Views of an abstract object are shared by making the associated view objects replicas of a special sharing object. The access rights to the views of a sharing object are shared by making guards that authorize actions independent of the identity of the user who invokes the actions. The Rendezvous constraint mechanism can be used by programmers to implement other kinds of sharing among view objects. Figure 8.15 shows the main components of a Rendezvous program.
For each multiuser program, Rendezvous creates a single abstract process, which stores the abstract objects defined by the program. Moreover, for each user of the multiuser program, it creates a view process, which stores all of the view objects created for that user. The abstract process and the view processes created for a multiuser program are lightweight processes that execute as part of a single heavyweight process.
Figure: Rendezvous Abstract and View Objects
Figure: Components of a Rendezvous Multiuser Program
Implementing the example user-interface: The application programmer would define abstract objects to encapsulate semantic values such as procedures and coverage information, view objects for defining their screen representations, and constraints for keeping view objects consistent with the underlying abstract objects. The programmer would create separate view objects for each user of the abstract objects displayed in edit windows but a single logical set of sharing view objects for the abstract objects displayed in the test windows. Rendezvous would automatically create a separate replica of the sharing view object for each user of the application and ensure that these replicas are always kept consistent. All abstract objects would be stored in a single abstract process while the view objects created for different users would be kept in different view processes. Access and concurrency control would be implemented by associating appropriate guards with rules that get input.
Unlike the other tools discussed so far, Rendezvous provides high-level support for three useful kinds of sharing: semantic sharing, image sharing, and complete sharing. Some of the other tools discussed so far such as shared windows systems support only one kind of sharing while others such as message servers enable arbitrary kinds of sharing but provide low-level facilities for implementing them. The constraint mechanism of Rendezvous also supports arbitrary sharing.
On the other hand, Rendezvous has all the performance drawbacks of the centralized window architecture since the abstract process and the associated view processes all execute at a central site. Moreover, like Colab, it does not provide high-level support for maintaining state shared by only a subset of the users of a multiuser application, dynamically changing the sharing, or flexible communication of changes to shared data. Finally, it does not automatically support concurrency control or access control.