• No results found

Switching between real-time and non-real-time collaborative editing

collaborative editing

As specified in the requirements of collaborative editing for collaborative program- ming, a very important requirement is that smooth, flexible switching between real- time and non-real-time collaborative editing should be supported in order to adapt to different phases or situations in a collaborative programming process.

1.6.1

Related techniques and systems

A naive approach for switching between real-time and non-real-time collaborative editing is to simply use separate real-time and non-real-time collaborative editing systems and manually switch between these two systems from time to time. This

34

approach has two major problems. First, it is difficult to achieve smooth switching between these two different systems because they were designed without any knowl- edge of each other and are likely to be incompatible in the sense that they view their data differently and do not provide any mechanism to share data between them [110]. For example, a group of programmers use a SCM system such as CVS [10] to do non-real-time collaborative editing of a shared source code file. When there is a need for them to switch to the real-time collaborative editing mode in order to interac- tively tackle an urgent issue by using a real-time collaborative editing system such asREDUCE [138], the switch process will not be smooth because the REDUCE sys- tem is unable to automatically obtain a proper document to start with. In fact, all participants have to stop non-real-time collaborative editing and reconcile a proper document for REDUCE to start with. Moreover, it is difficult to achieve flexible switching by allowing any participant to switch to any one of the two systems at any time. In the above example, before switching from non-real-time collaborative editing to real-time collaborative editing, all participants have to run a protocol involving a number of merging rounds to obtain a convergent copy of the shared source code file. That protocol could take several minutes or even hours to complete [9], depending on how far those copies are divergent and how effective the merging algorithm is.

Turn-taking is a concurrency control mechanism used by both real-time and non- real-time collaborative editing. Therefore, a commonly used approach for supporting switching between real-time and non-real-time collaborative editing is to use turn- taking as the common concurrency control mechanism to prevent inconsistent copies from happening. A representative system is the SEPIA hypertext authoring sys- tem [67], which allows work to be done in three different modes: individual, loosely coupled, and tightly coupled. When working on a document without concurrent users, an author works inindividualwork mode, which is a typical non-real-time collabora- tive editing mode. Multiple users are not allowed to do concurrent individual work

on the same document but are allowed to take turns to do individual work on the same document.

When a co-author works on a document already used by another author, all con- current users shift into loosely coupled mode, where multiple users collaboratively edit the same document in real-time by the technique of turn-taking in which the document may be edited by one user at a time while others may see the changes in real-time. If some co-author in a loosely coupled session feels the need for a real- time conference, the co-author can initiate a tightly coupled session with a group of specified loosely coupled collaborators to join in. In a tightly coupled session, col- laborators work in the way of WYSIWIS (What You See Is What I See) [129] by shared views [41, 62], telepointers [6, 115], and audio communication but real-time collaborative editing is still based on turn-taking.

This approach does support smooth, flexible switching between real-time and non- real-time collaborative editing [67]. But, as discussed in Section 1.4, turn-taking is a pessimistic concurrency control technique that does not support concurrent work. So, the disadvantage of this approach is that unconstrained concurrent editing is not supported in either real-time or non-real-time collaborative editing, which con- sequently does not meet the requirements of collaborative editing for collaborative programming.

1.6.2

Focuses and contributions

Notification is an essential feature in both real-time and non-real-time collaborative systems, which determines when, what, and how changes made by one user are prop- agated, applied, and reflected on other users’ interfaces [46, 125]. Therefore, our research has been focused on supporting smooth, flexible switching between real-time and non-real-time collaborative editing from the perspective of notification. One major contribution of our research on smooth, flexible switching between real-time

36

and non-real-time collaborative editing is a flexible notification technique to support flexible collaborative editing that integrates unconstrained, responsive, real-time col- laborative editing, unconstrained, syncretic, non-real-time collaborative editing, and smooth, flexible switching between real-time and non-real-time collaborative editing. A major issue in the flexible notification technique is that an efficient consis- tency maintenance solution is required for flexible collaborative editing. So the ma- jor contribution to the operational transformation technique is the extension of the technique, originally proposed for consistency maintenance in real-time collaborative editing, to support consistency maintenance in flexible collaborative editing. It in- cludes a new transformation control algorithm that has a linear time complexity, two notification algorithms that support propagation and acceptance of any notifica- tions at any time, and a notification propagation protocol that is efficient for both real-time and non-real-time collaborative editing. The flexible notification technique has been implemented in the web-based flexible collaborative editing system NICE

(Notification-flexible Collaborative Editing) for the purpose of testing the correct- ness, demonstrating the feasibility, and providing a vehicle to do a usability study and motivate future research on flexible collaborative editing.