Current configuration management systems promote workspaces that isolate developers from each other. This isolation is both good and bad. It is good, because developers make their changes without any interference from changes made concurrently by other developers. It is bad, because not knowing which artifacts are changing in parallel regularly leads to problems when changes are promoted from workspaces into a central configuration management repository. Overcoming the bad isolation, while retaining the good isolation, is a matter of raising awareness among developers, an issue traditionally ignored by the discipline of configuration management. To fill this void, we have developed Palantr, a novel workspace awareness tool that complements existing configuration management systems by providing developers with insight into other workspaces. In particular, the tool informs a developer of which other developers change which other artifacts, calculates a simple measure of severity of those changes, and graphically displays the information in a configurable and generally non-obtrusive manner. To illustrate the use of Palantr, we demonstrate how it integrates with two representative configuration management systems.

objects define underlying data while view objects define how these data are viewed and manipulated by users. 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 copies 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 that invokes the action. There are three main similarities between Rendezvous and Suite: First, like Suite it supports semantics, presentation, and access couplings 5 . Second, like Suite, Rendezvous supports a fine-grained coupling model that allows different view objects displayed to a user to be coupled differently with their counterparts displayed to other users. Third, the constraint mechanism supported by Rendezvous corresponds to th...

Groupware toolkits let developers build applications for synchronous and distributed computer-based conferencing. This chapter describes four components that we believe toolkits must provide. A run-time architecture automatically manages the creation, interconnection, and communications of both centralized and distributed processes that comprise conference sessions. A set of groupware programming abstractions allows developers to control the behavior of distributed processes, to take action on state changes, and to share relevant data. Groupware widgets let interface features of value to conference participants be added easily to groupware applications. Session managers let people create and manage their meetings and are built by developers to accommodate the group’s working style. We illustrate the many ways these components can be designed by drawing on our own experiences with GroupKit, and by reviewing approaches taken by other toolkit developers.

We have developed a new framework for supporting concurrency control in collaborative applications. It supports multiple degrees of consistency and allows users to choose concurrency control policies based on the objects they are manipulating, the tasks they are performing, and the coupling and merge policies they are using. Concurrency control policies are embodied in hierarchical, constructor-based lock compatibility tables. Entries in these tables may be specified explicitly or derived automatically from coupling and merge policies. In this paper, we motivate and describe the framework, identify several useful concurrency control policies it can support, evaluate its flexibility, and give conclusions and directions for future work. Keywords Concurrency control, collaborative systems, consistency criteria, coupling, merging, transactions INTRODUCTION When two or more users collaborate through jointly manip- ulating a shared object---be it an electronic whiteboard, a document, or ...

The need to merge different versions of an object to a common state arises in collaborative computing due to several reasons including optimistic concurrency control, asynchronous coupling, and absence of access control. We have developed a flexible object merging framework that allows definition of the merge policy based on the particular application and the context of the collaborative activity. It performs automatic, semi-automatic, and interactive merges, supports semanticsdetermined merges, operates on objects with arbitrary structure and semantics, and allows fine-grained specification of merge policies. It is based on an existing collaborative applications framework and consists of a merge matrix,which defines merge functions and their parameters and allows definition of multiple merge policies, and a merge algorithm, which performs the merge based on the results computed by the merge functions. In conjunction with our framework we introduce a set of merge policies for several u...

The Model View Controller (MVC) architecture has proven to be an effective way of organizing synchronous groupware applications. Distributed implementations of MVC, however, can suffer from poor performance. This paper demonstrates how optimized semi-replication of MVC architectures can lead to good performance over both local and wide area networks. We present a series of optimizations to network communication based on specific communication properties of groupware. These optimizations have been implemented in the Clock groupware development toolkit, allowing programmers to develop applications directly in the high-level MVC style, with Clock automatically providing optimized performance. Timings of an application developed in Clock show that usable speed was obtained in a highly interactive groupware application running between Toronto and Calgary, with a typical latency of 190 ms per round trip message. The paper discusses the tradeoffs involved in the algorithms, and presents timings to demonstrate the effectiveness of the different approaches. The timings show that when running over a wide area network, the best optimization can achieve a factor 60 speedup over the naive implementation of distributed MVC.

CSCW toolkits are designed to ease development of CSCW applications. They provide common, reusable components for cooperative system design, allowing application programmers to concentrate on the details of their particular applications. The underlying assumption is that toolkit components can be designed and implemented independently of the details of particular applications. However, there is good evidence to suggest that this is not true. This paper presents a new technique which allows programmers to express application requirements, so that toolkit structures can be adapted to different circumstances. Prospero is a toolkit which uses this technique to meet different application needs flexibly.

The correct and timely creation of systems for coordination of group work depends on the ability to express, analyze, and experiment with protocols for managing multiple work threads. We present an evolution of the Trellis model that provides a formal basis for prototyping the coordination structure of a collaboration system. In Trellis, group interaction protocols are represented separately from the interface processes use them for coordination. Since these protocols are interpreted (rather than being compiled into applications), group interactions can be changed as a collaborative task progresses. Changes can be made either by a person editing the protocol specification "on the fly" or by a silent "observation" process that participates in an application solely to perform behavioral adaptations. Trellis uniquely mixes hypermedia browsing with collaboration support. We term this combination a hyperprogram, and we say that a hyperprogram integrates the description of a collaborative t...

this paper, we motivate, describe, and illustrate the main components of FLECSE, thereby providing an initial answer to the following fundamental question: In what ways must a traditional software engineering environment be extended to allow software engineering tasks to be carried out more concurrently? A definitive answer to this question requires several iterations of (i) identifying concurrent software engineering scenarios, (ii) developing an environment that supports these scenarios, (iii) experimenting with the environment in controlled settings, and (iv) testing the environment in the field. We have carried out mainly steps (i) and (ii) of a preliminary iteration of this process, so our answers to this question are not yet ideal. However, we believe our work is a necessary and important step towards practical environments for supporting concurrent software engineering. In the remaining discussion we will examine five important themes of concurrent software engineering:

In this paper weinvestigate the appropriateness of formal specification languages for the description of user interface phenomena. Specifically,we are concerned with the distinction between continuously available information, whichwe call status, and atomic, non-persistent information, which we call events. We propose a hybrid model and notation to address status and event phenomena symmetrically.We demonstrate the effectiveness of this model for designing and understanding mixed control interaction, an especially important topic in the design of multi-user systems.