Flexible Notification for Collaborative Systems

Haifeng Shen and Chengzheng SunSchool of Computing and Information Technology

Griffith UniversityBrisbane, Qld 4111, Australia

fHf.Shen, C.Sung@cit.gu.edu.au

ABSTRACTNotification is an essential feature in collaborative systems,which determines a system’s capability and flexibility in sup-porting different kinds of collaborative work. In the pastyears, various notification strategies have been designed fordifferent systems. However, the design of notification com-ponents has been ad hoc, and the techniques used for sup-porting notification have been application-dependent. In thispaper, we contribute a flexible notification framework thatcan be used to describe and compare a range of notificationstrategies used in existing collaborative systems, and to guidethe design of notification components for new collaborativesystems. The framework has been applied to the design ofa notification component for a group editor, which uses asingle notification mechanism to support various notificationpolicies for meeting both real-time and non-real-time collab-oration needs. In addition, a new operational transformationcontrol algorithm has been devised in combination with thenotification component, which is significantly simpler andmore efficient than existing algorithms.

Keywords: Collaborative system, notification, group edi-tor, concurrency control, operational transformation.

INTRODUCTIONNotification is an essential feature in collaborative systems,which determines when, what, and how updates made by oneuser are propagated, applied, and reflected on other users’ in-terfaces. It is this feature that distinguishes collaborative sys-tems from traditional multi-user systems, such as databasemanagement systems and timesharing operating systems, wherea user is normally not notified of the actions performed byother users [6].

Notification plays an important role in determining a sys-tem’s capability and flexibility in supporting different kindsof collaborative work. If a system has adopted a notificationstrategy that frequentlypropagates one user’s actions to oth-ers, then this system is capable of supporting real-time (orsynchronous) collaborative work, where multiple users can

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CSCW’02,November 16-20, 2002, New Orleans, Louisiana, USA.Copyright 2002 ACM 1-58113-560-2/02/0011 ...$5.00.

collaborate at the same time. In contrast, if a system hasadopted a notification strategy that infrequentlypropagatesone user’s actions to others, then this system is more suitablefor supporting non-real-time(or asynchronous) collaborativework, where multiple users can collaborate at different times.Usually, one collaborative system uses only one notificationstrategy, and existing collaborative systems have been classi-fied to be either real-time or non-real-time. However, there isno technical reason that a system cannot use multiple notifi-cation strategies to support both real-time and non-real-timecollaborative work.

In the past years, various notification strategies have been de-signed for different collaborative systems to meet their spe-cial collaboration needs. For example, the REDUCE(REal-time Distributed Unconstrained Cooperative Editing) editor[16] has focused on achieving high responsiveness but adopteda simple notification strategy: operations performed on theshared document by one user is immediately and automati-cally propagated to other users and reflected on other users’interfaces as soon as possible. REDUCEalso provides somelimited support for controlling the granularity of propagatedoperations: operations can be at the level of either individ-ual characters or arbitrary length strings [8]. In the Internet-based real-time chatting tool ICQ [7], a message is sent assoon as the user hits the Sendbutton, and reflected on otherusers’ interfaces on arrival. In the version control systemCVS(Concurrent Versions System) [2], a user can edit thecopied document as long as s/he wishes. Updates made onthe shared document by one user is not made available to oth-ers until the user manually issues the commitcommand [2],and updates made by other users are not integrated into thelocal copy unless the user manually issues the updatecom-mand [2]. In all these collaborative systems, the design of no-tification components has been ad hoc, and techniques usedfor supporting notification have been application-dependent.Little research has been done on generic aspects of notifica-tion to provide an integrated and unified view of existing no-tification strategies, and to provide a guideline for the designof new notification strategies.

In collaborative applications, notification can be used to sup-port exchanging messages. For example, messaging sys-tems like Email or ICQ [7] use notification to support mes-sage exchange. In addition, notification can be used to sup-

5077

port group awareness. For example, ICQ [7] uses notifica-tion to inform others of a participant’s status change (e.g.,online/offline), and NESSIE[12] uses notification to informothers of a task that has been completed by a participant.Notification can also be used to support concurrency con-trol in order to maintain consistency of shared artifacts. Forexample, REDUCE[16] uses propagation of operations [8]and operational transformation [16, 15] as the concurrencycontrol mechanism to maintain consistency among replicatedcopies, and CVS[2] uses propagation of documents, docu-ment merging [14], and mutual exclusive locking as the con-currency control mechanism to maintain consistency amongreplicated copies.

In this paper, we contribute a flexible notification frameworkthat can be used to describe and compare a range of notifica-tion strategies used in existing collaborative systems, and toguide the design of notification components for new collab-orative systems. In the proposed framework, the notificationpolicy that determines when and what to notify is separatedfrom the notification mechanism that determines how to no-tify. The notification policy part of the framework consistsof a set of basic and generic parameters which can be used todefine a spectrum of notification polices suitable for meetingdifferent collaboration needs. The notification mechanismpart consists of a set of basic and generic technical compo-nents which can be used to support various notification poli-cies. Finally, we show how to apply this framework to thedesign of a flexible notification component for a group editor,which can support various notification polices for meeting arange of collaboration needs. In addition, a new operationaltransformation control algorithm has been devised in combi-nation of the notification component for concurrency control,which is significantly simpler and more efficient than exist-ing algorithms.

The rest of this paper is organized as follows. The followingsection presents a flexible notification framework. Then thenext two sections describe the design of a notification compo-nent for a group editor by means of the proposed framework.Comparison to related work is discussed in the following sec-tion. Finally the paper is concluded with a summary of ourmajor contributions and future work.

A FLEXIBLE NOTIFICATION FRAMEWORK

The proposed framework consists of a notification policy partand a notification mechanism part. We first discuss the policypart.

To achieve flexible notification, we differentiate two direc-tions of notifications. One is the Outgoing Notification direc-tion (ON), which is about when, what, and how updates madeby a user are propagated to others. The other is the IncomingNotification direction (IN), which is about when, what, andhow updates made by other users are accepted and reflectedon a local user’s interface. Two parameters frequencyandgranularity are provided to define various notification poli-cies.

Notification frequencyThe frequency parameter determines the “when” aspect ofnotification, that is, when a notification is to be propagated/accepted.

REDUCEICQEmailCVS

Collaborative systems

Notification frequency

Figure 1: Relationship between notification frequencyand collaborative systems

According to the frequency of notification, we can sort col-laborative systems in a linear order, with less frequently noti-fying systems ordered before more frequently notifying sys-tems. As shown in Figure 1, non-real-time collaborative sys-tems, such as CVS and the Email system, occupy the leftspectrum of notification frequencies, and real-time collabo-rative systems, such as ICQ and REDUCE, are using the rightspectrum of notification frequencies.

System-triggeredI: Instant

S: Scheduled

User-triggered U: User-controlled

Figure 2: Notification frequency parameter values

The frequency parameter may take different values, whichare shown in Figure 2. Values for ON/IN diretions, denotedas ONF/INF, can be classified into two categories: system-triggered and user-triggered. In system-triggered notifica-tion, the system automatically propagates/accepts notifica-tion. If ONF = I, every update made by a user would beinstantly propagated, and if INF = I, every update made byanother user would be instantly accepted and reflected on alocal user interface. ICQ is an example of using INF = I,where arrived messages are instantly reflected on the user in-terface. If ONF/INF = S, the system propagates/accepts noti-fications as scheduled. Scheduling is application-dependentand may be based on some rules that are related to externalevents. Scheduling rules could be either implicitly built inthe application or explicitly configured by users. For exam-ple, in REDUCE, the INF has the following system built-inscheduling rule: a remote operation is accepted only whenit is causally ready. In many email programs, new messageswill be checked out in the user-specified time interval. Inuser-triggered notification, notification is propagated/acceptedby the user’s explicit commands. For example, in CVS, up-dates made by a user are not made available to others unlessthe user issues the commit command [2].

Different collaborative systems usually take different notifi-cation frequency parameter values. For example, as shown

5178

in Figure 3, in CVS, all participants have the same param-eter values: ONF/INF = U. So updates made by a user arenot propagated unless s/he issues the commit command, andthese updates are not applied to another user’s copy unlessthat user issues the update command. In ICQ, all partici-pants have the same parameter values: ONF = U and INF =I. So a message is not sent out unless the user hits the Sendbutton, and when the message arrives at a remote site, it willbe displayed on the remote user’s interface immediately. InREDUCE, all participants have the same parameter values:ONF = I and INF = S. So each operation generated at a siteis instantly propagated and when it arrives at another site, itis executed when causally ready.

CVS Email ICQ REDUCE

ONF U U/S U IINF U S/S I S

Figure 3: Frequency parameter values used in exam-ple systems

A collaborative system may allow different participants tohave different notification parameter values. For example, inthe Email system, consider two usersA andB work this way.Both of them have specified a time interval to check emails.SupposeB sendsA an email butAwas away from her/his of-fice. Before her/his departure,A has configured her/his emailsystem with the capability of automatically replying every re-ceived email with a pre-described message telling s/he is onvacation. When B’s email is checked out in A’s email sys-tem, it will be automatically replied with the pre-describedmessage. So A’s frequency parameter values are: ONF = S;INF = S while B’s frequency parameter values are: ONF =U; INF = S.

Notification granularityThe granularity parameter determines the “what” aspect ofnotification, that is, which updates is going to be propagated/accepted.

We use ONG/ING to denote the granularity parameter forON/IN directions respectively. The granularity parameter maytake two values A (All) and S (Selective). If ONG/ING =A, all updates accumulated since last propagation/acceptanceare propagated/accepted. Most existing collaborative sys-tems adopt this granularity policy. For example, in CVS,when a user issues the commit command, all updates accu-mulated since the last commit operation are propagated. IfONG/ING = S, users can select updates among those thathave been accumulated since the last propagation/acceptanceto propagate/accept.

Selective notification is flexible and usually triggered by userswith explicit selection criteria. But if selection criteria canbe pre-defined, notification could also be automatically trig-gered by the system. Selection criteria are application depen-dent. Some typical examples are:� Time criterion: a user can selectively propagate/accept up-

dates made within a certain period of time.

� Object criterion: a user can selectively propagate/acceptupdates made to certain objects.

� Type criterion: a user can selectively propagate/accept cer-tain types of updates.

� Version criterion: a user can selectively propagate/acceptupdates made in certain versions of a shared artifact.

� User criterion: a user can selectively notify certain usersof her/his updates or selectively accept updates made bycertain users.

These criteria can be used as filters for the notifying site to se-lect certain updates to notify, or for the notified site to selectcertain notifications to accept. Carzaniga et al. has presenteda systematical approach in [4] to select appropriate collec-tion of events using filters and patterns. Although its primarygoal is different from selective notification, most of the ideascan be directly applied or extended to achieve selective noti-fication.

An example of ONG = S is the Netmeeting [9] conferencingsystem where a user’s desktop environment can be sharedwith others. In this system, a user is allowed to notify oth-ers of all updates made in her/his desktop environment, orselectively notify others of updates made in particular appli-cations. So the selection is based on the Object criterion. Anexample of ING = S is CVS where a user is able to specify aversion number to select updates made till that version to beapplied into his copy. So the selection is based on the Versioncriterion.

In general, if the frequency of notification is high, each noti-fication tends to have a small granularity, and ONG/ING = Ais usually used. If the frequency of notification is low, eachnotification tends to have a large granularity if ONG/ING =A, or have a small granularity if ONG/ING = S. The notifi-cation frequency and granularity parameters can be used todefine a range of notification policies used in existing col-laborative systems, and to guide the designs of notificationpolicies for new systems.

Notification mechanismIn the policy part, we have explored the “when” and “what”aspects of notification. This section focuses on the “how”aspect, which is about the notification mechanism part.

To support a range of notification policies, a notification bufferis needed to buffer updates in order to allow users to selectany updates to propagate/accept at any time. Furthermore,in order to support separated notification policies for ON andIN, two separate buffers Outgoing Buffer (OB) and IncomingBuffer (IB) should be used as notification buffers. OB storesall locally performed updates so that a user is able to selectany local updates to propagate at any time. IB stores all re-mote propagated updates so that a user is able to select anyremote updates to accept.

An Outgoing Notification Executor(ONE) component and anIncoming Notification Executor(INE) component are neededto carry out various outgoing and incoming notification poli-cies respectively. In particular, the ONE component manages

5279

the OB buffer, selects a collection of updates from OB, andproperly reformulates the selected updates to propagate. TheINE component manages the IB buffer, selects a collectionof updates from IB, and properly reformulates the selectedupdates to accept.

Internet

ONE

OB

INE

IB

Mechanism

Policy

Site 2

NPP

ONE

OB

INE

IB

Mechanism

Policy

Site 3

NPP

ONE

OB

INE

IB

Mechanism

Policy

Site 1

NPP

Figure 4: A flexible notification framework

A very important component in notification mechanism isNotification Propagation Protocol (NPP), which is neededfor propagating updates from the OB at the notifying site tothe IB at the notified site. There are two alternatives to designthe protocol. One is the poll approach in which the notifiedsite polls updates from the OB at the notifying site. An exam-ple of using this approach is CVS in which a user uses the up-date command to poll updates into her/his working copy. Theother is the Push approach in which the notifying site pushesupdates into the IB at the notified site. The Publish/Subscribeparadigm [3, 1] is a typical example of using this approach,where the publisher pushes certain messages to certain sub-scribers who are interested in.

In summary, the notification framework is shown in Figure 4.The policy part makes notification policies. The notificationmechanism part consists of notification buffers and notifi-cation executors for executing notification policies, and thenotification propagation protocol for supporting communi-cation and interaction between the notifying site and notifiedsites. In the following sections, we demonstrate how to ap-ply the proposed notification framework to the design of anotification component for a group editor, which can supportvarious notification polices for meeting a range of collabora-tion needs.

A NOTIFICATION COMPONENT FOR A GROUP EDITORA group editor is a typical collaborative system where multi-ple participants can edit a shared document that is replicatedamong participating sites. In existing group editors, notifi-cation policies for meeting real-time collaboration needs areused in real-time systems like REDUCE while notificationpolicies for meeting non-real-time collaboration needs areused in non-real-time systems like CVS.

Notification policiesOur objective is to design a notification component for agroup editor, which uses a single generic notification mech-anism to support a range of notification policies for meetingboth real-time and non-real-time collaboration needs. Suchan integrated system is desirable in practice because real-time and non-real-time systems could be both needed in de-veloping a project at different stages or under different cir-cumstances. A real-time system is required when a groupof users need frequent interaction to achieve some commongoal (e.g., collaboratively debugging a computer program).A non-real-time system is required if real-time collaborationis not achievable, or collaborators do not want to coordi-nate with one another interactively (e.g., collaborators con-currently write different chapters for a book). There are twopossibilities that real-time collaboration is not achievable.One is network connection is discontinuous/unreliable (e.g.,in mobile and wireless computing environments). Another iscollaborators are located in different time zones. However, itis neither easy for users to be familiar with multiple systemsnor convenient to manually switch among different systemsfrom time to time. It is highly desirable for people to usethe same editor to work in non-real-time collaboration andreal-time collaboration modes.

Real-time systems like REDUCE capture updates to the shareddocument as operations (or events). When a user wants tonotify others of an update, the corresponding operation willbe propagated to other sites [8]. Propagation of operations inreal-time systems is very frequent. The timestamping tech-nique is usually used to capture concurrent relationships amongoperations, and the operational transformation technique [16,15] is usually used for concurrency control to maintain con-sistency among replicas. Each propagation message in real-time systems may contain a small collection of operations,normally one operation. For each received operation, a so-phisticated transformation control algorithm like GOTO [15]needs to be executed to get the correct execution form of theoperation to achieve consistency. While this approach workswell for real-time systems, it is unsuitable for non-real-timesystems. First of all, non-real-time systems tend to havea large and nondeterministic number of participants, whichmakes it unrealistic to timestamp operations with a fixed sizeof state vectors. Moreover, in non-real-time systems, propa-gation messages are less frequent but each message normallycontains a large number of operations. It would be wastefuland inefficient to timestamp individual operations and trig-ger a sophisticated transformation control algorithm for eachreceived operation.

Non-real-time systems like CVS, do not capture updates inthe form of operations/events. Instead, each ON notifica-tion transfers the updated document into the repository andexecutes a time-consuming text differentiation algorithm likediff [10] there to generate deltas [2] between the updated doc-ument and its original version. Each IN notification trans-fers the original version and versions made by remote users

5380

from the repository, and executes a time-consuming merg-ing algorithm like diff3 [10] at the notified site to merge up-dates made at remote sites into the local copy. This approachcannot be used for real-time systems because it is unaccept-able to transfer entire documents over the network back andforth, and execute time-consuming [10] text differentiationand merging algorithms just for notifying a single update.

To support a range of notification policies by a single groupeditor, we devise a flexible notification component with ageneric notification mechanism to support various notifica-tion policies. Because concurrency control is a key issue ingroup editors, we also show how concurrency control is inte-grated in the proposed notification mechanism.

Notification algorithmsOB stores operations sequentially generated and executed atthe local site. So operations in an OB are sorted in the causalorder from left to right. IB stores operations propagated fromremote sites. These operations have been contextually seri-alized in the sense that for any Ox and Oy in an IB, if Ox

is at the left side of Oy, then it must be: (1) Ox is contextu-ally preceding Oy [16], or (2) Ox is concurrent with Oy, butOy has taken into account Ox’s effect by operational trans-formation [16]. How to achieve contextual serialization willbe explained in the next section. Operations in the OB andIB at the same site are concurrent [16]: given any Ox andOy, where Ox is in IB and Oy is in OB, Ox and Oy must beconcurrent operations.

To propagate any operationOx inOBl at site l, the followingtwo steps should be done. First, Ox must be transposed to theplace between the last propagated operation and the first un-propagated operation in OBl in order to support various out-going notification granularities. Ox is transformed into theform that Ox is contextually preceding all unpropagated op-erations so that whenOx arrives at a remote site r, there is nooperation in IBr, which has not arrived but casually beforeOx in OBl. This step is done by the LTranspose procedure,which is based on operational transformation functions.

There are two types of primitive transformation functions [16]:one is the Inclusion Transformation function – IT (Oa, Ob),which transforms operation Oa against operation Ob in sucha way that the impact of Ob is effectively included in the pa-rameters of the output operation O0

a; and the other is the Ex-clusion Transformation function –ET (Oa,Ob), which trans-forms Oa against Ob in such a way that the impact of Ob iseffectively excluded from the parameters of the output oper-ation O0

a. LTranspose(L) procedure is defined to transpose(i.e., transform and shift) the right-most operation in L to theleft-most position in L.

Procedure 1 LTranspose(L)f for (k = jLj; k > 1; k ��)

f /* transform */L[k] := ET (L[k], L[k-1]);L[k-1] := IT (L[k-1], L[k]);/* shift */

O := L[k];L[k] := L[k-1];L[k-1] := O;

gg

In the second step, Ox must be transformed against all op-erations in IBl before propagation. The propagation proto-col ensures operations in IBr must be either operations inOBl that have been propagated beforeOx, or operations thathave also appeared in IBl. Consequently, when Ox arrivesat a remote site r, it can be simply appended in IBr. Onthe other hand, operations in IBl must also be transformedagainst the concurrent operationOx in order to preserve theirintentions [16]. Therefore operations inOBl and IBl need tobe transformed against each other symmetrically. The SLOT(Symmetric Linear Operation Transform) control algorithmis defined as follows.Procedure 2 SLOT(L1, L2)f for (i = 1; i�jL2j; i++)

for (j = 1; j�jL1j; j++)SIT(L2[i], L1[j]);

g

The SIT(Oa, Ob) (Symmetric Inclusive Transformation) pro-cedure is defined to inclusively transform Oa and Ob sym-metrically.Procedure 3 SIT(Oa, Ob)f O0

a := IT (Oa, Ob);O0

b := IT (Ob, Oa);Oa := O0

a;Ob := O0

b;g

To execute any operation Oy in IBl at site l, the followingtwo steps need to be done. First, Oy must be transposed tothe left-most side of IBl in order to support various incomingnotification granularities. Ox is transformed into the formthat Ox is contextually preceding the rest of operations inIBl so that it will be executed in the right context. Second,Oy is transformed with unpropagated operations in OBl topreserve their intentions. Operations in OBl should be con-current with operations in IBl. ButOy must have been trans-formed with those propagated operations in OBl before theirpropagations. SoOy only needs to be transformed with thoseunpropagated operations in OBl.

In summary, the AnyONE algorithm for the ONE componentis defined as follows to propagate a list of selected operations[ON1

, � � �, ONk] from OB.

Algorithm 1 AnyONE([ON1, � � �, ONk

])Suppose OB = [O1, � � �, Om, � � �, On]. A pointer calledILPO (Identifier of Last Propagated Operation) is maintainedto remember the last propagated operation in OB. ILPO =ID(Om) where ID(Om) is Om’s ID. So Oi(1 � i � m) arecalled propagated operations, and Oj (m< i � n) are calledunpropagated operations. The following steps are executedto propagate the list of operations [ON1

, � � �, ONk] where m

<N1, � � �, Nk � n.

5481

1. Transpose ON1, � � �, ONk

to the place between Om andOm+1 by repeatedly using the LTranspose procedure:

for (i = 1; i� k; i++) f LTranspose([Om+1, � � �, ONi]);g

After then, OB becomes [O1, � � �, Om, O0

N1, � � �, O0

Nk,

O0

U1, � � �, O0

Ul] where m< U1, � � �, Ul � n and U1, � � �, Ul

6= N1, � � �, Nk.

2. If IB is empty, skip this step. Otherwise suppose IB = [O1,� � �, Or]. SLOT([O0

N1, � � �, O0

Nk], IB) needs to be executed.

After then, [O0

N1, � � �, O0

Nk] becomes [O

00

N1, � � �, O

00

Nk], OB

becomes [O1, � � �, Om, O00

N1, � � �, O

00

Nk,O0

U1, � � �,O0

Ul], and

IB becomes [O0

1, � � �, O0

r].

3. Propagate the list of operations [O00

N1, � � �, O

00

Nk] in a noti-

fication message. The pointer ILPO is set to ID(O00

Nk).

Correspondingly, the AnyINE algorithm for the INE compo-nent is defined as follows to execute a list of selected opera-tions [OE1

, � � �, OEk] where 1 � E1, � � �, Ek � n from IB

= [O1, � � �, On].

Algorithm 2 AnyINE([OE1, � � �, OEk

])

1. Transpose OE1, � � �, OEs

to the left-most position in IB

by repeatedly using the LTranspose procedure:for (i = 1; i � k; i++) f LTranspose([O1, � � �, OEi

]);gAfter then, IB becomes [O0

E1, � � �, O0

Ek, O0

U1, � � �, O0

Ul]

where 1 < U1, � � �, Ul � n and U1, � � �, Ul 6= E1, � � �, Ek .

2. If OB contains no unpropagated operation, skip this step.Otherwise suppose OB = [O1, � � �,Om, � � �,On] with ILPO= ID(Om), SLOT([Om+1, � � �,On], [O0

E1, � � �,O0

Ek]) needs

to be executed. After then, [O0

E1, � � �,O0

Ek] becomes [O

00

E1,

� � �, O00

Ek], IB becomes [O

00

E1, � � �, O

00

Ek, O0

U1, � � �, O0

Ul],

OB becomes [O1, � � �, Om, O0

m+1, � � �, O0

n].

3. Execute operations O00

E1, � � �, O

00

Eksequentially, and re-

move them from IB. After then, IB = [O0

U1, � � �, O0

Ul]. A

pointer called ILAO(Identifier of Last Accepted Operation)is maintained to remember the last accepted operation fromIB. So ILAO is set to ID(O

00

Ek).

The ILPO and ILAO pointers are needed in notification prop-agation protocol, which is explained as follows.

Notification propagation protocolWe adopt the push approach for the notification propagationprotocol in order to efficiently support a wide range of noti-fication policies because the poll approach is not suitable forsupporting those notification policies for meeting real-timecollaboration needs [5].

Notification is contextually serialized. The serialization canbe implemented in many ways. We use Notifier-based so-lution as an example to illustrate our solution. The Notifieris a notification server [11], which acts as as a centralizedserialization point and a message relaying agent.

Sequential propagation An option is sequential propaga-tion, where only one notification is outstanding at any time.In this case, the Notifier manages a token that circulates among

participating sites, and a waiting queue to queue token re-quests. Only the site that has been granted the token is ableto propagate a notification.

Before propagating a notification, the notifying site sends aToken-Request message to the Notifier, waiting for the Token-Grant message from the Notifier. After being granted thetoken, the site propagates the notification piggybacked withthe Token-Release message to the Notifier. When the Notifierreceives the notification and the the Token-Release message,it forwards the notification to all interested notified sites. Byusing the Notifier as a message relaying agent, causal rela-tionships among notifications are automatically guaranteed.The Notifier also dispatches the token according to the wait-ing queue, and sends the Token-Grant message to the nextgranted site. When receiving a notification, the notified sitesimply appends operations piggybacked in the notificationinto its IB.

Sequential propagation simplifies concurrency control becausefor anyOx inOBk at site k, all operations that are concurrentwith Ox must only be in IBk. As a result, for concurrencycontrol, Ox only needs to be transformed against all opera-tions in IBk before propagation. On the other hand, for anyOy in IBk, all operations that are concurrent with Oy mustonly be in OBk . As a result, for concurrency control, Oy

only needs to be transformed against all operations in IBk

before execution.

However, sequential propagation is inefficient for support-ing notification policies for meeting real-time collaborationneeds. For propagating each notification that may containonly one operation, three extra messages Token-Request, Token-Grant, and Token-Release have been sent between the Noti-fier and the notifying site. Although the Token-Release mes-sage can be avoided by piggybacking it in the message thatcontains propagated operation, and the Token-Grant messagecan be possibly avoided by piggybacking it in the messagethat contains the operation forwarded from the Notifer, thereis definitely no way to avoid the Token-Request message.

Concurrent propagation So we propose another solution,which allows a site to propagate its notification without firstrequesting the token, thus effectively eliminating the Token-Request message. In this solution, multiple sites could con-currently propagate their notifications to the Notifier. As aresult, for any Ox in OBk at site k, not only are operationsin IBk concurrent with Ox but also are those operations ontheir way towards IBk.

The proposed solution is called SCOP (Symmetric Contextually-serialized Operation Propagation) protocol. As shown in Fig-ure 5, sequential propagation is relaxed to be sequential ac-cess to the Notifier, that is sequential access to the IncomingMessage Queues (IMQ) at the Notifier for queuing incomingnotification messages towards notified sites. The OutgoingMessage Queues (OMQ) at the Notifier are used to queuenotification messages propagated from notifying sites. Tran-sit IMQs/OMQs (TIMQ/TOMQ) are used to illustrate those

5582

notification messages on the way between a notifying siteand the Notifier or between the Notifier and a notified Site.It is those notification messages in TIMQ/TOMQ that makeconcurrency control difficult. One thing that should be clar-ified is those IMQs/OMQs are conceptual data structures forillustration purpose only.

OB1

IB 1

OM Q1

IM Q 1

OM Q2

IM Q 2

OB2

IB 2

Site 1 Site 2

Notifier

TOM Q1 TOM Q2

TIM Q 1 TIM Q 2

Figure 5: The SCOP propagation protocol

The challenge of this protocol is to ensure each operationwould never miss out the chance of being transformed withany concurrent operation no matter where it is. For example,as shown in Figure 5, an operation Ox in OB1 could be con-current with another operation Oy, which could be in IB1,TIMQ1, IMQ1, OMQ2, TOMQ2, or OB2.

A notification message contains two fields: a list of opera-tions L and a pointer ILTO (Identifier of Last TransformedOperation). ILTO is used to remember the last operation inIB with which operations in L have been transformed. L isachieved with the AnyONE algorithm and ILTO is achievedby the getILTO(IB, ILAO) function defined as follows.Function 1 getILTO(IB, ILAO): ILTOf if (jIBj == 0)

ILTO = ILAO;else

ILTO = ID(IB[jIBj-1]);return ILTO;

g

As shown in Figure 5, when the notification message: L

= [O00

N1, � � �, O

00

Nk]; ILTO = ID(Or) propagated from Site

1 arrives at the Notifier, it will be put in OMQ1. WhenSite 1 gains access to the Notifier, the following steps willbe executed repeatedly until OMQ1 is empty: (1) The re-moveMessage procedure is executed to remove messages inIMQ1 with operations in whose Ls operations in the notifi-cation message have been transformed; (2) The SLOT algo-rithm is executed to transform operations in the notificationmessage with the operations in the remaining messages inIMQ1; (3) The updateILTO procedure is executed to updatethe ILTO pointer; (4) The notification message is removedfromOMQ1, put in the IMQs for all notified sites, and prop-agated from the Notifier to all notified sites, for example, Site2.

The removeMessage procedure and the updateILTO proce-dure are defined as follows.

Procedure 4 removeMessage(IMQ, ILTO)f for (i = 0; i < jIMQj; i++)

if (ID(IMQ[i].L[jLj-1]) == ILTO) break;if (i < jIMQj)

for (j = 0; j � i; j++) remove(IMQ[0]);g

Procedure 5 updateILTO(IMQ, ILTO)f if (jIMQj > 0)

ILTO = ID(IMQ[jIMQj-1].L[jLj-1]);g

When the notification messages arrives at Site 2, the follow-ing steps would be done: (1) removeOperation procedure isexecuted to remove operations OB2 with which operationsin the notification message have been transformed; (2) TheSLOT algorithm is executed to transform operations in thenotification message with the remaining propagated opera-tions in OB2; (3) Operations in the notification message areappended to IB2.

The removeOperation procedure is similar to the he removeMes-sage procedure, which is defined as follows.

Procedure 6 removeOperation(OB, ILTO)f for (i = 0; i < jOBj; i++)

if (ID(OB[i]) == ILTO) break;if (i < jOBj)

for (j = 0; j � i; j++) remove(OB[0]);g

In summary, the SCOP notification propagation protocol isdescribed as follows.

Protocol 1 SCOP1. At the notifying site k, AnyONE algorithm is executed to

get the L field and getILTO(IBk, ILAOk) procedure isexecuted to get the ILTO field for a notification message.Then the notification message is propagated.

2. At the Notifier, when the message arrives, it will be put inOMQk. When Site k gets access, the following will bedone:while (jOMQkj > 0)f Msg = OMQk[0];

removeMessage(IMQk, Msg.ILTO);for (i = 0; i < jIMQkj; i++)

SLOT(IMQk[i].L, Msg.L);updateILTO(IMQk, Msg.ILTO);remove(OMQk[0]);for (any notified site l)f append(Msg, IMQl);

propagate(Msg, Site l);g

g

3. At the notified site l, when a notification message Msg ar-rives, the following will be done:removeOperation(OBl, Msg.ILTO);for (i = 0; i < jOBlj; i++)f append(OBl[i], tempList);

if (ID(OBl[i]) == ILPOl)

5683

break;gSLOT(tempList, Msg.L);for (j = 0; j < jMsg:Lj; j++)

append(Msg.L[i], IBl);

Significance of the SLOT algorithmThe SLOT transformation control algorithm is much sim-pler and more efficient than other algorithms such as GOTO.There are three other important advantages. Firstly, it is freeof state vectors. State vectors are usually needed to captureconcurrent relationships among operations, which have beenachieved because the notification protocol ensures operationsin OB and IB at the same site are concurrent. Secondly, it isfree of ET transformation functions. Although theoreticallyIT and ET are reversible [16], that is, if O0

a = IT (Oa, Ob),then Oa = ET (O0

a, Ob), this reversibility cannot be alwaysguaranteed in reality due to information loss in IT transfor-mations [16].

Finally, it is free of the TP2 (Transformation Property 2) [15].TP2 imposes a condition that the transformation of an oper-ation against a pair of operations is independent of the orderthe pair of operations are transformed against each other. Inpractice, it is hard to verify this condition and if it is vio-lated, consistency may not be maintained. The reason whythe SLOT algorithm is free of TP2 is that under no circum-stance an operation could be transformed against the samepair of operations but in different orders. An operation O

in OBl at site l may be transformed against the set of op-erations in IBl, which has an unique order. O may also betransformed against operations in OBr1 at remote site r1 andoperations in OBr2 at remote site r2, but operations in OBr1

and OBr2 must be totally different.

AN EXAMPLEConsider the scenario that such a group editor is used in abrainstorming discussion. The discussion consists of a groupof participants and a reviewer who collects ideas, assessesthem, and gives comments. Those participants use the noti-fication policy: ONF = I, ONG = A, INF = I, and ING = Ato work in real-time mode because they want their ideas tobe assessed by the reviewer and receive comments as soonas possible. On the contrary, the reviewer uses another no-tification policy: INF = U, ING = A, ONF = U, and ONG= S to work in non-real-time mode in order to avoid keepingreceiving new messages while s/he is focusing on reviewingcurrent ideas. On the other hand, after reviewing for a periodof time, the reviewer will selectively broadcast comments ongood ideas.

We take two sites as an example, where the user at Site 1 isa participant and the user at Site 2 is a reviewer. The doc-ument initially contains “ abcd” . The participant performedan operationO1 = del[1, 2, bc] to delete two characters start-ing from position 1 (i.e., “ bc” ). The document then becomes“ ad” . Concurrently the reviewer performed an operation O2

= del[0, 1, a] to delete character “ a” and a subsequent oper-

ation O3 = ins[2, 1, x] to insert a character “ x” at position2 (i.e., between the character “ c” and “ d” ). The documentthen becomes “ bcxd” . According to the notification policyat Site 1, operation O1 will be propagated instantly as gener-ated. Suppose the reviewer happens to selectively propagateO3 concurrently. As a result, notifications on O1 and O3 arepropagated to the Notifier concurrently. Suppose Site 1 gainsaccess to the Notifier first. As shown in Figure 6, before no-tifications on O1 and O3, OB1 = [O1], OB2 = [O2, O3], andILPO1 = ILAO1 = ILPO2 = ILAO2 = null.

O 1OB1

IB 1

O 2, O 3OB2

IB 2

OM Q1 OM Q2

IM Q 1 IM Q 2

ILPO:nullILAO:null

ILPO:nullILAO:null

Figure 6: Before AnyONE(O1) and AnyONE(O3)

AnyONE(O1) and AnyONE(O3)In AnyONE(O1), because ONG = A, there is no need to exe-cute the LTranspose procedure. Furthermore, because IB1 isempty, there is no operation in IB1 with which O1 needs tobe transformed. As shown in Figure 7, a notification messageMsg1 with L = [O1] and ILTO = getILTO(IB1, ILAO1) =null is then propagated to the Notifier. Finally ILPO1 is setto ID(O1).

ILPO:ID(O '3)

ILAO:null

O 1OB1

IB 1

O '3, O

'2

IB 2

M sg1OM Q1

IM Q 1 IM Q 2

ILPO 1:ID(O 1)

ILAO 1:null

M sg1([O 1],null)

M sg2

M sg2([O'3],

null)

OM Q2

OB2

Figure 7: After AnyONE(O1) and AnyONE(O3)

In AnyONE(O3), because ONG = S, LTranspose ([O2, O3])is executed to transpose O3 ahead of O2. After then, OB2 =[O0

3, O0

2] whereO0

3 = ins[3, 1, x] andO0

2 = del[0, 1, a]. SinceIB2 is also empty, there is no operation in IB2 with whichO0

3 needs to be transformed. As shown in Figure 7, a notifica-tion messageMsg2 withL = [O0

3] and ILTO = getILTO(IB2,ILAO2) = null is then propagated to the Notifier. FinallyILPO2 is set to ID(O0

3).

The propagation of O1

When Msg1 arrives at the Notifier, it is put into OMQ1. Asshown in Figure 8, when Site 1 gets access, because IMQ1

is empty, there is no need to execute removeMessage, SLOT,and updateILTO procedures. Msg1 will be removed from

5784

OMQ1, put into IMQ2, and propagated to Site 2. WhenMsg1 arrives at Site 2, because Msg1.ILTO = null, nothingwill be removed from OB2 by the removeOperation (OB2,Msg1.ILTO) procedure. After the execution of SLOT([O0

3],Msg1.L) = SLOT([O0

3], [O1]), OB2 = [O00

3 , O0

2] where O00

3 =ins[1, 1, x], and Msg1.L = [O0

1] where O0

1 = del[1, 2, bc], isthen appended to IB2.

ILPO:ID(O 1)

ILAO:nullILNO:ID(O '

3)

ILEO:null

O 1OB1

IB 1

O ''3, O'2

O '1

OM Q1

IM Q 1 M sg1IM Q 2

M sg2

M sg1([O 1],null)OM Q2

OB2

IB 2

M sg1([O 1],null)

Figure 8: The propagation of O1

The propagation of O0

3

When Msg2 arrives at the Notifier, it is put into OMQ2. Asshown in Figure 9, when Site 2 gets access, becauseMsg2.ILTO= null, nothing will be removed from IMQ2 by the removeMes-sage (IMQ2, Msg2.ILTO) procedure. After the executionof SLOT(Msg1.L, Msg2.L) = SLOT([O1], [O0

3]), Msg1.L =[O0

1] whereO0

1 = del[1, 2, bc] andMsg2.L = [O00

3 ] whereO00

3

= ins[1, 1, x]. After the execution of updateILTO(IMQ2,Msg2.ILTO), Msg2.ILTO = ID(O1). Then Msg2 is re-moved from OMQ2, put into IMQ1, and propagated to Site1. When it arrives at Site 1, after the execution of remove-Operation (OB1, Msg2.ILTO), O1 is removed from OB1,and ILPO1 = null. Because there is no propagated operationin OB1, there is no need to execute SLOT, and operations inMsg2.L = [O

00

3 ] is appended to IB1 as is.

ILPO:ID(O '3)

ILAO:nullO ''3 O '

1

OB1

OM Q1

O ''3, O'2

M sg2 M sg1

ILPO:nullILAO:null

M sg2([O''3], ID(O 1))

IB 2

OB2

OM Q2

IM Q 2IM Q 1

IB 1

M sg2([O''3],

ID(O 1))

Figure 9: The propagation of O0

3

AnyINE(O00

3 ) and AnyINE(O0

1)Because INF = I at Site 1, O

00

3 will be executed immediatelyon arrival. In AnyINE(O

00

3 ), because ING = A, there is noneed to execute the LTranspose procedure. Furthermore, be-cause OB1 is empty, there is no unpropagated operation inOB1 with whichO

00

3 needs to be transformed. SoO00

3 = ins[1,1, x] is executed as is on the current document state “ ad” .After execution, as shown in Figure 10, ILAO1 = ID(O

00

3 ),

and the document becomes “ axd” . O3 generated at Site 2has been correctly executed at Site 1.

When the reviewer decides to accept notifications from theparticipant, s/he explicitly issues a command. Because ING= A, there is no need to execute the LTranspose procedure.As shown in Figure 10, ILPO = ID(O0

3) indicates that O0

2

in OB2 is an unnpropagated operation. So O0

1 in IB2 needsto be transformed with O0

2 in OB2. After the execution ofSLOT([O0

1], [O0

2]), OB2 becomes [O00

3 , O00

2 ] where O00

2 =del[0, 1, a]. O

00

1 = del[0, 2, bc] is executed on the currentdocument state “ bcxd” . After execution, ILAO2 = ID(O

00

1 ),and the document becomes “ xd” . O1 generated at Site 1 hasbeen correctly executed at Site 2.

OB1 O ''3, O''2OB2

OM Q1

M sg2 M sg1

ILPO:null

ILAO:ID(O ''3)

ILPO:ID(O '3)

ILAO:ID(O ''1)

OM Q2

IB 2IB 1

IM Q 1 IM Q 2

Figure 10: After AnyINE(O00

3 ) and AnyINE(O0

1)

A COMPRESSION ALGORITHMA challenging issue is that notification buffers could growdramatically in long duration collaboration sessions. We havedevised a novel compression algorithm CLOM (Compressa Log by Operational Merging) [14] to compress logs foroperation-based version control systems [14]. This algorithmis able to minimize the size of a log as well as the numberof operations within it by the proposed operational merg-ing technique [14] and the operational transformation tech-nique [16, 15]. The algorithm can be directly applied to thecompression of notification buffers.

The operational merging technique is also important for theLTranspose procedure to support selective notification. Aswe know, ET transformation may not succeed if the effectsof two causal operations are overlapping [14]. The opera-tional merging technique can be used to make their effectsdisjointed [14], thus making ET transformation successful.

COMPARISON TO RELATED WORKSome key issues for notification servers have been discussedin [13]. Their work focused on deriving a conceptual frame-work to guide the design of notification servers while ourwork focuses on designing algorithms to tackle technical is-sues involved in notification. Some issues have been raisedin [13]. For example, the concept of “pace impedance” hasbeen proposed to allow the notification pace between the no-tifying site and the notification server to be different fromthat between the notification server and the notified side. Weaddressed this issue by separating outgoing and incoming no-tification policies. Some issues that we have addressed were

5885

not mentioned in [13]. For example, the design of a noti-fication service should consider how to effectively supportconcurrency control if updates are made on shared artifacts.

NSTP (Notification Service Transfer Protocol) [11] provideda simple and general application-independentnotification ser-vice for sharing artifacts in synchronous multi-user applica-tions. Its goal was to provide notification service for syn-chronous applications, therefore it did not address issues re-lated to the support of asynchronous applications. Moreover,because updates are made on shared artifacts, a centralizedlocking-based serialization protocol was designed for con-currency control. This solution is simple and independent ofapplications, but it may not be scalable for some applicationsbecause the notification server has to maintain all shared ar-tifacts and it could become a bottleneck as the number ofshared artifacts grows to some extent.

NESSIE [12] provided an application-independentgeneric no-tification infrastructure for asynchronous application sharingsystems. Because its goal was to provide task-based groupawareness, notifications are consequently made on the basisof tasks instead of individual events. As a result, it is un-suitable to be used for notification service in synchronousapplications. Another major difference between [12] and ourwork is they focused on the issues of using notification tosupport group awareness while our work focuses on the is-sues of using notification to support concurrency control.

CONCLUSIONS AND FUTURE WORKIn this paper, we propose a flexible notification framework inwhich notification policy is separated with notification mech-anism. In the policy part, we use two parameters frequencyand granularity to define a spectrum of notification polices.In the mechanism part, separated notification buffers and sep-arated notification executors are used to support various out-going/incoming notification policies.

We have applied the framework to the design of a notificationcomponent for a group editor, which supports a range of noti-fication policies for meeting both real-time and non-real-timecollaboration needs. The notification mechanism consists oftwo algorithms AnyONE and AnyINE, and a propagation pro-tocol SCOP.

In addition, we contribute a new operational transformationcontrol algorithm SLOT for concurrency control, which issignificantly simpler and more efficient than existing algo-rithms. Furthermore, it is free of state vectors, free of ETtransformation functions, and free of the TP2 transformationcondition.

We are now in the process of implementing such an inte-grated group editor called NICE (Notification-flexIble Col-laborative Editing) system by means of the proposed flexiblenotification component.

ACKNOWLEDGEMENTSThe work reported in this paper has been partially supportedby an ARC (Australian Research Council) Large Grant (000-

00711).

REFERENCES1. Banavar, G., Chandra, T., Mukherjee, B., and Nagara-

jarao, J. An Efficient Multicast Protocol for Content-based Publish-Subscribe Systems, in Proc. of Interna-tional Conference on Distributed Computing Systems,1999. 262-272.

2. Berliner, B. CVS II:Parallelizing software develop-ment, in Proc. of Winter USENIX’90. 341-352.

3. Birman, K.P. The process group approach to reliabledistributed computing. Communications of the ACM36, 12 (1993), 37-54.

4. Carzaniga, A., Rosenblum, D.S., and Wolf, A.L. De-sign and Evaluation of a Wide-Area Event NotificationService. ACM Transaction on Computer Systems 19, 3(2001), 332-383.

5. Edwards, W.K., Mynatt, E.D., Petersen, K., Spre-itzer, M.J., Terry, D.B., and Theimer, M.M. Designingand Implementing Asynchronous Collaborative Appli-cations with Bayou, in Proc. of ACM Sympisium onUser Interface Software anf Technology, 1997. 119-128.

6. Ellis, C.A., and Gibbs, S.J. Concurrency control ingroupware systems, in Proc. of ACM SIGMOD Con-ference on Management of Data, 1989. 399-407.

7. ICQ. ICQ is Online Happiness. http://web.icq.com.8. Li, D., Sun, C., Zhou, L., and Muntz, R.R. Operation

propagation in real-time group editors. IEEE Multime-dia 7, 4 (2000), 55-61.

9. Microsoft. Microsoft Windows Netmeeting.http://www.microsoft.com/windows/netmeeting/.

10. Myers, E. An O(ND) difference algorithm and its vari-ations. Algorithmica 1, 2 (1986), 251-266.

11. Patterson, J.F., Day, M., and Kucan, J. Notifica-tion Servers for Synchronous Groupware, in Proc. ofCSCW’96. 122-129.

12. Prinz, W. NESSIE: An Awareness Environment forCooperative Settings, in Proc. of the sixth Europeanconference on Computer Supported Cooperative Work,1999. 391-410.

13. Ramduny, D., Dix, A., and Rodden, T. Exploringthe design space for notification servers, in Proc. ofCSCW’98. 227-235.

14. Shen, H., and Sun, C. A Log compression algorithmfor operation-based version control systems, in Proc. ofInternational Computer Software and Application Con-ference, 2002. To appear.

15. Sun, C., and Ellis, C.A. Operational transformationin real-time group editors: issues, algorithms, andachievements, in Proc. of CSCW’98. 59-68.

16. Sun, C., Jia, X., Zhang, Y., Yang, Y., and Chen,D. Achieving convergence, causality-preservation, andintention-preservation in real-time cooperative editingsystems. ACM Transaction on Computer Human Inter-action 5, 1 (1998), 63-108.

5986