A framework for collaboration and interaction across the Internet
Department of Computer Science, Queen Mary & Westfield College, University of London, Mile End Road, London E1 4NS, UK. timk@dcs.qmw.ac.uk.
A framework for collaboration and interaction across the Internet
Department of Computer Science, Queen Mary & Westfield College, University of London, Mile End Road, London E1 4NS, UK. timk@dcs.qmw.ac.uk.
Mushroom [1] is a framework under construction for collaboration and interaction across the Internet. This framework supports the dynamic creation and management of Mrooms, which are environments for collaborative work and containers for shared objects. Although we base our work primarily on a `room' metaphor [Henderson and Card 1985], we recognise the need to provide a task-based representation of Mrooms. Users access Mrooms through links on World Wide Web pages, and they may navigate between them by following links; however, access control is applied. In Mrooms, users can share applications and information objects such as documents and whiteboards. Users also share tools for awareness of and communication with other users in the Mroom. Mrooms are normally persistent, and users can either interact synchronously (in the same room at the same time) or asynchronously (users occupy the room at different times, but observe one another's changes to information objects). Objects within rooms may be active (for example, in distance-learning a lecturer may create interactive objects for student experiments). Further motivation for Mushroom is given in [Kindberg 1995].
1.1 Related work
Cruiser [Root 1988] and CoDesk [Marmolin et al 1991] both attempted to structure multi-user interaction and information sharing around a 2D `room' or `workspace' metaphor. Systems such as DIVE [Carlsson and Hagsand 1993] and MASSIVE [Greenhalgh 1994] explore the use of 3D space in the collaborative setting. The Mushroom approach is that, while realistic or 3D-graphical representations of working environments are sometimes useful, the representation of a collaborative environment should be chosen to fit the task. For example, a shared spreadsheet may be what is required for collaboration, and it is pointless to make this have room-like properties. However, we retain two general notions from the room metaphor: boundary, which provides security and integrity guarantees for shared objects and communication; and space, in which users are aware of one another and the shared objects they work on.
BSCW [Bentley et al 1995] provides collaborative environments using World Wide Web pages, which represent directories of shared objects and are associated with group membership. Notwithstanding the introduction of Java and other languages for mobile programs that can be embedded in WWW pages, we prefer currently to develop purpose-built user interfaces and investigate the extent to which they can be integrated with the Web. HTTP is unsuited to object sharing in that it is inefficient and does not directly support replication. By contrast, system designs already exist that are purpose-built for collaborative asynchronous data sharing, for example DocMan [Baeker and Busbach 1996]; and the Mbone and higher-level multicasting software such as SID2 [Hagsand 1995] provide facilities for update distribution that allow us to build synchronous tools.
WORLDS [Tolone et al 1995] is a framework that provides spaces for work and interaction, called locales. WORLDS has focused on the structure and evolution of locales, and navigation between them. Its design does not guarantee security or integrity of shared data.
Lotus Notes [Lotus 1993] is a commercial product that provides protected information sharing. However, support for collaboration is limited. There is no systematic way of providing awareness of users' activities. Support for conflict management is rudimentary. Update propagation occurs according to predetermined schedules, precluding synchronous working.
MUDs (Multi-User Dungeons) and MOOs (MUD, Object-Oriented) provide facilities for users to encounter one another in navigable worlds made up of rooms (or other spaces) and objects. MOOs enhance MUDs by being programmable, so that users can import new types of objects. Every MOO is tied to a single server, and all text typed by users is sent to the server and then distributed from the server to the other users. Response tends to be slow. MOOs are used for education and for the same sorts of purpose as Internet Relay Chat, but with enhanced imaginative possibilities. Several commercial versions such as Palace and WorldsAway exist, providing graphically represented shared worlds based on MOO technology.
1.2 Outline
Section 2 describes the requirements that Mushroom is designed to meet. Section 3 discusses the model of Mrooms, addressing concurrency control and awareness. Section 4 outlines a system architecture for a prototype implementation and Section 5 concludes the paper with a brief statement of outstanding problems.
Task-based data representation. We make as few assumptions as possible about the type of the collaboration or interaction that takes place in an Mroom. Mrooms are screen-based workspaces with 2D or 3D representations to aid in the recognition of objects and users. The representational structure is to be configurable to meet the needs of the task in hand. For example, an Mroom could be a spreadsheet (enhanced for collaboration); it could be a collection of large-grained objects in a desktop-like arrangement; or it could be a virtual world.
Dynamic Mroom creation. Mrooms are required to facilitate collaboration and interaction for dynamic groups of users with changing needs. Our hypothesis is that a user-driven facility to create Mrooms on the fly will be useful, reflecting changes in the set of tasks in which each user is engaged, and changes in user focus on activities within those tasks.
Concurrency and asynchronicity. It is to be possible for an individual user to participate in several collaborative or interactive sessions concurrently - although at any point in time she or he would normally concentrate on just one. Given global time differences, different working patterns and the possibility of network disconnection, a user should be able to make progress without others being present or connected at the same time.
Scalability. Like the World Wide Web, Mushroom is to scale across the Internet to many users and Mrooms. The measure of system scalability is primarily interactive response time. Interaction between many users engaged in the same task or gathering tends to be ineffective, and it is envisaged that users will create Mrooms to support smaller groups.
Concurrency control. Effective concurrency control is essential for groupware. Concurrency control in groupware is discussed in [Kindberg 1996]. The main requirements particular to groupware described there are:
Cooperation. The concurrency control mechanisms should not interfere with users' need to cooperate with one another - for example, to demonstrate updates to one another.
Dynamic set of users. Concurrency control must be correctly applied even though the set of users involved in a session varies over time. Users joining a groupware session should be given a view of the application's state that is consistent with the current views of other users in the session.
Managing latencies. For the groupware application to be usable the time lags between making a user-interface action (e.g. clicking on a button) and seeing the results on the screen must be kept below the threshold where they inconvenience the user. The user interface should accommodate unavoidably high latencies, by moderating the user's expectations.
Object- or class-specific control. Consistency requirements vary between objects or types (classes) of objects, so concurrency control must be applied selectively. For example, it may not matter if two views of a shared whiteboard differ by a pixel or two; but it may be crucial that two views of the same part of a shared document do not differ textually at all.
Resolution rather than abortion. Where optimistic techniques are used, the concurrency control system should give users the option of resolving conflicts, rather than aborting work. This is particularly true of long-lived transactions, which are common in groupware. For example, a programmer may update source code files over several days. The concurrency control system should not discard such a large effort because of a conflict with other changes. The system should assist in avoiding the conflict in the first place.
Undo. The net effect of changes that several users make concurrently can be hard to predict; it is essential that users should be able to recover previously agreed versions of shared objects.
Integrity. Concurrency control is needed to maintain data integrity in the face of potentially conflicting concurrent accesses. But integrity is a more general notion. Users may need to place general constraints that the objects in an Mroom must satisfy. For example, all documents are required to conform to a house style - and an attempt to bring a non-conformant document into the Mroom is to fail.
Security. Designated users are to be able to apply a security policy for the protection of objects and privacy of communication within an Mroom. Mrooms themselves are to be a unit of protection: only designated users may enter an Mroom and thereby communicate or observe communication, and interact with objects within the Mroom. Also, users are to be able to place restrictions on which objects may enter the Mroom, and associate objects with their own access control lists for users in the Mroom.
Openness and configurability. Present-day groupware tools are largely incompatible with one another. Mushroom aims to provide a common framework (API) for which programmers can develop tools. It is to be possible to install new types of session control and concurrency control. Security policies and the representational layout of an Mroom are to be configurable.
Users should be able to import new types of object into Mrooms, and other users should be able to enter the Mroom and access them even though the objects have behaviours that they have never met before. For example, in a distance-learning application, a lecturer needs to be able to arrange presentations around objects that the students have not previously encountered; in general a user may wish to present him/herself to others using an individualised representation. The implication of this is a facility for object classes (that is, method code) to be loaded dynamically into client programs.
Audio. Audio communication is essential for serious synchronous collaborative work, but because of bandwidth and latency limitations it remains to be seen how successfully networked audio can be integrated (as opposed to using external telephone links).
Support for objects that are not group-aware. While providing a framework for group-aware objects such as collaborative document editors, Mushroom also needs to support objects that can only be created and edited by single users using conventional tools. For example, it should allow an author to create a file in MS-Word and install it into an Mroom for others to view.
Figure 1. Boundary provides access control; space provides concurrency/integrity control
3.1 Boundaries, spaces and views
An Mroom consists of a boundary and a space (see Figure 1), which are represented through one or more views, reflecting a separation of concerns.
The boundary provides security: privacy of communication and access control over the movement of objects and users across itself.
The space maintains a directory mapping names to attributes of objects and users inside the Mroom; and it applies concurrency control and more general integrity constraints over objects moving across the boundary.
A view represents the users and objects inside the Mroom. Typically it represents a desktop-like arrangement; but it could equally be a single document (such as a Web page or a spreadsheet) or a 3D graphical representation of a virtual world. Figure 2 shows a prototype default Mroom. The default view shows objects and users in separate areas. In principle, the same Mroom can have several views to suit different users.
Figure 2. Prototype default Mroom.
At a low level, a boundary is simply an access control list for the space together with communication protection settings. However, it is represented in the user interface, and users drag user icons and objects across it. An Mroom has one or more owners, who alone are able to configure the boundary and space - for example, to apply a security policy.
Users may in general either view or be present in a given Mroom. Browsing users view a snapshot of the contents of the Mroom (including users); this may be incomplete, e.g. for security reasons. Those present in the Mroom may allow viewers to communicate with them, to negotiate entry or discuss their activities. A user Fred becomes present in an Mroom in order to interact. Users (including Fred) can then see a representation of Fred in the Mroom; he can communicate with other users over the Mroom's private channels; and he can interact with the objects in the Mroom, subject to access control and concurrency control constraints.
Becoming present in an Mroom or ceasing to be present is achieved by dragging an icon representing oneself across the Mroom's boundary (the Mroom appears in view form before the user enters it - it may be transformed when the user crosses inside it). A user may by default remain present in an Mroom even though he or she is not currently interacting there. For example, the user has gone home but will resume work in the morning. Of course, an Mroom's owner can eject a `nuisance' user - for example, one who is present but who has not interacted in the Mroom for a long time.
3.2 Mrooms, their contents and concurrency control
The significance of boundary crossing for objects is: one drags an object to an Mroom in order to work on it in - or to attempt to integrate it in - a separate, well-defined context; and to enable others to know what one is doing.
Every object of concern to us exists in an Mroom (in principle any type of object may be brought into an Mroom). A user creates Mrooms either from a standard template or by forking an existing Mroom. After a fork operation, the child Mroom is defined to initially contain references to all the objects in the parent Mroom - providing read-only access to those objects. Users normally subsequently create new objects in the Mroom or drag objects into it for updating. To drag an object from one Mroom to another is to create a copy of it to use in the destination Mroom. The space provides a naming context: a bound name resolves in the child to the attributes of an object in its space if one matching the name is found there, and otherwise to those of an object in the parent Mroom.
Mushroom provides a concurrency control and integrity framework but leaves the choice of mechanisms and policy to the user. An Mroom is a unit of consistency and, more generally, data integrity. We make the following basic distinctions:
Example 1. In an Mroom maintained by the Internet Anarchists Collective, no objects are canonical and any user in the Mroom may freely update the contents - by dragging when they have single-user editors, or in situ where they have group-aware editors.
Example 2. A set of examination regulations is maintained as a canonical object in the BSc Sub-board Mroom. Users can read it and annotate it in the Mroom, meaning that others see the annotations when they view it. But no-one may change the core text in the Mroom.
Example 3. Two programmers, Jim and Mary, edit a set of source-code files drawn from a larger collection. The programmers each fork an Mroom for the purpose and drag the files they want to work on into it; the other files in the collection (which they need to compile the binary) are accessible read-only via references to them in the original Mroom.
We use the last example to illustrate the point that Mushroom provides a framework for awareness. Jim is motivated to enter the source-code Mroom in order to interact with objects (including other programmers) within it; other users, such as Mary, then become aware of Jim. When Jim drags an object out of the original Mroom to work on it, the system places a link to his Mroom next to the object in the original Mroom and all forked copies of it, so that users such as Mary can view Jim's working Mroom (and hence at least a snapshot of his activity), and can communicate with him if necessary. Programmers' Mrooms are equipped with tools such as whiteboards and group-aware editors, so that Jim and Mary can collaborate if they discover a potential for conflicting updates.
In general, when a user attempts to drag a canonical object, each boundary object consults the corresponding space object (which in turn can consult the dragged object) to decide whether crossing is possible, and if so what the effect is. The following are some obvious possibilities:
A space can refuse entry to an object that break other types of constraint, not just that of consistency with other objects. For example, it can refuse entry to a document that breaks `house-style' structural rules, or a source-code file that does not compile.
Figure 3. Viva-scheduling Mrooms.
3.3 Another example: viva scheduling
Students studying for the Advanced MSc in Computer Science at QMW, University of London are examined on their project by two examiners in a viva (viva voce - oral examination). The project organiser places viva objects in an Mroom for this purpose. Each viva object describes a student, his or her project title and the date, time and place for the viva. Vivas are canonical objects. Academic staff in the department sign up as examiners. Figure 3 shows the viva-scheduling Mroom with viva objects in it; it also shows versions of the Mroom that Jim Kirk and Mary Shelley have forked. Each has dragged two viva objects into his or her Mroom, with the intention of signing up as an examiner (they may change their minds). They have to enter the canonical Mroom to drag any objects out of it, so each can see that the other is concurrently selecting vivas. Furthermore, the appearance of mushroom links above viva objects tells them which objects have been dragged into other Mrooms; by clicking on the links, they can see a snapshot of the other's Mroom. Either may attempt to enter the other's Mroom in order to discuss any conflicts.
As it turns out, there are no conflicts in the figure. There is no substantive distinction between `examiner 1' and `examiner 2', so the viva-scheduling Mroom can easily add them both as examiners on the viva that they have both picked, when they both submit their updates. The Mroom's space is programmed to perform further integrity checks. In particular, it checks that neither is involved in two vivas at the same time; and it checks that no data other than the examiner entries in the viva object have been modified.
Figure 4. System architecture (S = server, W = workstation, M = Space replica).
4.1 Managing object versions and live replicas
Mushroom maintains a store of named objects for each Mroom. The space object is used to manage the objects in an Mroom as a consistent whole. Recall that it provides a naming context, storing attributes for each object in the Mroom. Among these attributes are a version number, the locations of replicas of the object, integrity/concurrency control procedures and settings (which we shall outline) and an access control list. The space also records other, application-specific attributes. For example, in a document-as-Mroom, it records the object's location in the document. We outline the main data associated with a space as follows:
space: name <,version number> -> attributes attributes = versionNumber isCurrent replicaLocations integrityControlAttributes: handleEntry() handleExit() concurrencyControlState (e.g. notifications) accessControlList otherAttributes
Mushroom stores a collection of persistent, read-only versions of each object, which may be freely replicated. This allows the users to keep track of object histories and to rely on being able to revert to a previous stage of development should this become necessary. Users with sufficient access rights add as many versions of an object as they like in an Mroom using the Store operation (see Table 1). Any user with sufficient access rights can access a particular version of an object fred using the ReadVersion operation given an identifier <fred, versionNumber>. There is also an operation Install on the space object, to install a version as the current version. The name fred (without a version number) is bound to the current version, and this version is returned by a ReadCurrent operation. An optional side-effect of ReadCurrent is for Mushroom to notify the recipient if another version is subsequently installed as the current version.
Group-aware objects are implemented as collections of live replicas: replicas of the object that are updated on a best-effort basis. That is, whenever a user updates the object (using a live replica) all the live replicas are updated. For example, a shared spreadsheet or whiteboard is implemented as a collection of live replicas. The operation GetLiveReplica obtains an up-to-date replica of a named object, and causes the client to join the update group for that object. This means that Mushroom automatically propagates all updates to the client.
| Operation | Effect |
| Store | Add version of existing object |
| Install | Make named version the current version |
| ReadVersion | Obtain copy of named version of object |
| ReadCurrent | Obtain copy of current version, and obtain notification when new version installed |
| GetLiveReplica | Obtain replica of object and join update group |
Table 1. Basic storage-related operations.
Table 1 summarises the storage-related operations we have described. We give the following examples to motivate this set of operations (which is not complete).
Exam regulations document supporting annotations. We introduced this above as an example of a canonical, group-aware object. Users may not change the regulations in the Mroom; but they may annotate them there, and annotations are visible to those viewing the document through a group-aware editor. To annotate the document, the user launches the group-aware editor (GetLiveReplica); updates are reflected in other users' replicas and persistent replicas in servers. To update the regulations, the user must drag the document to a different Mroom, update it and drag the new version back. The space may refuse it.
vi-edited source code file. This is a canonical, group-unaware object. Users depend upon it and it has interdependencies with other files. The editor vi does not support collaborative editing. The user must drag a copy of this object out of the Mroom (ReadCurrent), edit it and drag it back (Store and Install). The space may refuse to accept the new version.
Microsoft Word document containing a programmer's notes. This is an example of a non-canonical, group-unaware document. The programmer may make any change he or she likes to the document without affecting the overall integrity of the Mroom's contents. The user must drag a copy of this object out of the Mroom (ReadCurrent), edit it and drag it back (Store and Install) to make the changes visible to others. The space will always accept the new version.
Whiteboard. This is an example of a non-canonical, group-aware object. To view and update the whiteboard, the user launches the application (GetLiveReplica); apart from access control, there are no restrictions on updates, and they are automatically reflected in other users' replicas and server-stored persistent replicas.
The system invokes procedures for dragging canonical objects into and out of Mrooms, supplied or selected by the user. When a user tries to drag an object into an Mroom, the system calls an entry handler, which detects whether a consistency or integrity conflict would arise from installing the object and, optionally, handles the conflict. A conflict handler may advise the user about the conflict. It may even update the dragged object and perhaps other objects to resolve the conflict - similar to a merge procedure as used in the Bayou replicated storage system [Terry et al 1995].
The space-entry for an object can also contain an exit handler. This can be used, for example, to implement locking or to alter the set of operations that may be performed on the object in the destination Mroom.
4.2 Managing replication
Replicating a space object and the group-aware objects it contains is necessary for high availability but has consequences for consistency and security. The normal space consistency requirement is that all users must agree on the set of objects in the space and their attributes - that replicas converge to be identical. We are investigating an optimistic approach, in which the system designates changes to the space as tentative initially, and later as committed or repudiated. A repudiated object is one involved in a conflict: for example, you and I concurrently attempt to Install different object versions as a new object called fred. The system represents changes as tentative through the view. For example, objects that have been dragged into the Mroom appear faded or they appear in an `entrance hall' until their presence is committed or repudiated.
We are considering implementing the optimistic scheme by making the system choose a total order for all updates that users make to the space. Eventually all replicas of the space receive confirmation of all updates and the specification of their total ordering. The ordering is used to decide upon commitment or repudiation. For example, the `first' of two users who added a new object called fred succeeds; the other's attempt is repudiated.
On the issue of security, a malicious or faulty site can arbitrarily change a local copy of an object, regardless of the user's supposed access rights. Similarly, any site can try to receive or send communication messages belonging to an Mroom. The only way to protect the integrity of objects and communication is for correctly functioning sites to ensure that only bona fide object code, object versions, updates and communication are accepted for integration, application and audio rendering. This protection is to be achieved by a combination of an Mroom encryption key and user keys, and is the subject of ongoing study [Rowley and Dollimore 1996].
We are currently engaged in a feasibility study investigating these issues, using the Java language and existing Mbone-based software packages.
Hagsand, O. (1995). SID2 Interface Specification. http://www.sics.se/~olof/sid2.html
Kindberg, T. (1995). The Mushroom Manifesto. ftp://ftp.dcs.qmw.ac.uk/pub/distrib/publications/Mushroom/manifesto.ps.gz
Kindberg, T. (1996). Notes on concurrency control in groupware. ftp://ftp.dcs.qmw.ac.uk/pub/distrib/publications/Mushroom/ccInGroupware.ps.gz
Lotus (1993). System administration manual, Lotus Notes release 3, 1993.