|
Distributed Authoring on the Web with the bscw shared Workspace system
|
| bet | 6/9 | | Sana | 22.07.2021 | | Hajmi | 34,45 Kb. | | #15603 |
Collaboration within a group will often involve some form of joint document production, requiring support for the management of document versions. Version management is a complex area and can be divided into a number of aspects; with respect to document production (instead of, say, distributed software development) the following are some of the possible functions a version management component should provide:
¥ Archive: to preserve document versions for security and recoverability, so that individual userÕs updates are not lost;
¥ History: to provide information on what was changed, when, by whom (and possibly for what purpose - c.f. RCS which asks for descriptions on check-in of a new version);
¥ Synchronization: to avoid problems that may occur with concurrent access to documents (e.g. Ôdirty readsÕ), usually involving some variant of check-in/out or copy-modify-merge.
We now look at the support BSCW provides for each of these functions.
3.2.1 Archive function
In the current version of BSCW we support a linear version scheme. Clicking a documentÕs ÔversionÕ button (Figure 1) places a document under version control, so that new versions of the document are added to the linear history without destroying previous versions. A version archive is automatically created when a document is placed under version control, and this is shown in the representation of the document in the BSCW interface (see the document ÔACM draftÕ in Figure 1). Users can unfold a version archive to access previous versions, as in Figure 1, or click on the ÔversionsÕ link in the interface. Clicking on the document name always returns the latest version but each previous version can be accessed with a distinct URL. Uploading a document to the archive automatically creates a new version, as does cutting an existing document from a workspace folder and dropping it in the archive.
The current archive function is therefore very simple, but provides the basic function of preserving document versions for security and recoverability. In conjunction with a project partner in the CoopWWW project, we are developing a richer version management component based on the RCS system. This allows more sophisticated archiving schemes including branching, as well as more efficient version storage based on deltas.
3.2.2 History function
The provision of history information is very important to give users an overall ÔawarenessÕ of the state of a collaborative project. In the area of CSCW - Computer Supported Collaborative Work - awareness is a major research topic, and the need to provide mechanisms which provide historical (asynchronous) and notification-based (synchronous) awareness of other usersÕ activities a primary focus of system development. The role of such awareneness information is to establish a context in which users can coordinate their work based on knowledge of other usersÕ activities and their own relationships to the collaboration.
The support BSCW provides for historical, asynchronous awareness centers on the BSCW event service. This service provides users with information on the activities of others with respect to the objects in a workspace. Events are triggered when a user performs an action in a workspace, such as uploading a new document, downloading (ÔreadingÕ) an existing document, creating a new document version etc. The system presents recent events to each user as event icons (e.g. ÒNewÓ) in the workspace listing (Figure 1), which users can click on to learn more about who caused the event, when, and so on. In this context, ÔrecentÕ means events which have occurred for an object since the user last Ôcaught upÕ; an operation by which users can tell the system they are aware of the events that have occurred so far and no longer wish to see them in the workspace (like catching up articles in an Internet newsgroup). Events can be caught up at different levels, from individual objects to complete workspace folder hierarchies.
The event mechanism applies to all objects in the workspace, and provides a history function for the version management service. However, this mechanism requires users to actively check the workspace (ÔreloadÕ the page) to be informed of new activities. To address this, users of the version management service can also take advantage of a notification-based service provided by a small helper application similar to a mail notification (ÔbiffÕ) tool. This application, currently running on WindowsÕ95/NT platforms, periodically checks with a BSCW server for new events and notifies the user (by changing color) if events have occurred since the last check: double clicking on the notification icon opens an event browser window (Figure 4).
3.2.3 Synchronization function
We have experimented with different approaches to supporting the synchronization aspects of version management in BSCW. In a previous version of the system (Bentley et al., 1995) we implemented a check-in/out model based on strict locking. On check-out a lock was created denying write access to a versioned document. The lock was then released on check-in. Experiences with this approach showed that richer lock management is required, e.g. to allow Ôlock stealingÕ in certain circumstances. More generally, we found that for many groups involving well-known colleagues such strict locking is not so necessary, as recoverability is provided by the archive function preventing accidental overwriting of each userÕs changes. Rather, the system should provide a more powerful means of reflecting the status of the current version with respect to other usersÕ activities.
The current approach thus uses a ÔsofterÕ method of locking designed to allow users to describe the current status of a versioned document. A Ôsoft-lockÕ is simply a note attached to a versioned document which is displayed whenever a user attempts to download the current version or perform an operation on it. Clicking on the note icon (ÔACM draftÕ in Figure 1) will also display the contents. Such a note can be used to indicate that a document is currently being edited, that ÔSection 2Õ is currently being revised and so on, and is intended to provide a method for users to coordinate their work without the more restrictive policies (or the complexity) of a strict locking approach. Users can still perform all operations by clicking on links included when the note is displayed.
We are currently extending this idea of a note to apply to other workspace objects, not just documents under version control. For some applications, however, such a loose model of controlling updates may not be so appropriate, and we are looking at ways to provide users with different options through a clear separation of the archive, history and synchronization functions of the version management service. At the moment such stricter control is provided by the access control service in BSCW.
Access rights in BSCW can be set on a per-object basis to control the operations available to different users. It is possible to Ôopen-upÕ access to make a document accessible without authentication to ÔpublishÕ it as a standard Web document (Section 3.1.2). It is also possible to restrict update rights to a small group (possibly one user) to simulate a strict lock. The concepts of locking and access control are clearly related; what is also clear from our experiences with BSCW is that a number of factors determine the support required by a group from access control, suggesting that such services must be flexible to handle different methods of working.
|
| |
