JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 81

New Optimized Generic Operational

Transformation Consistency Control Algorithms
Supporting String Operations in Collaborative
Applications
1
Santosh Kumawat, 2Ajay Khunteta

Abstract—Real-time cooperative editing systems allow multiple users to view and edit the same document at the same time from multiple
sites connected by some networks. Consistency maintenance is one of the challenging job in the design and implementation in such type of
systems. Operational Transformation (OT) is an established optimistic consistency control method in collaborative applications. All OT algo-
rithms only consider two characters based primitive operations insert and delete. Our algorithm supports two string based primitive opera-
tions. This paper presents a new optimized generic OT control algorithm SITOSq and MswapDsqD that has reduced the runtime overheads
of recursions of ITOSq [12] algorithm and swapDsqD [12] algorithm respectively. Also SITOL and MswapLO have reduced recursion as com-
pared to ITOL [12] and swapLO [12].

Index Terms— Operational transformation, Consistency control, String operations

——————————  ——————————

1 INTRODUCTION

O T[10, 11] is an optimistic consistency control me-

thod that lies in the heart of many collaborative ap-
plications such as group editors and Google Wave1.
The method replicates the shared data at cooperating
sites. Local operations are always executed as soon as
they are generated by the user. Remote operations are
transformed before execution to repair inconsistencies.
Group editors usually replicate the shared docu-
ment at each site .Each user’s operations is executed on
the local replica immediately without being blocked or
delayed. Operations are then propagated to remote sites
and concurrency control protocols are sought to repair
inconsistencies. Traditional concurrency control me-
thods, such as locking and serialization, are found un-
suitable for interactive groupware applications. Moreo-
ver, concurrency control methods in traditional distri-
buted systems in general only consider content consis-
tency, i.e., that all replicas eventually converge, while
overlooking intention consistency, i.e., that the con-
verged content is what the users want.
Consistency maintenance is a fundamental issue
in many areas of computing systems, including database
systems [Bernstein et al. 1987], distributed systems [Bir-
man et al. 1991], and groupware systems [Baecker 1992;
Sun et al. 1998]. Real-time collaborative graphics editing
systems allow a group of users to view and edit the same
graphics document at the same time from geographically
dispersed sites connected by communication networks.
Consistency maintenance in the face of concurrent ac-
————————————————
 Santosh Kumawat is M.Tech Scholar in Poornima College of Engineering, group editors for either asynchronous or synchronous
Jaipur, Rajasthan, India.
 Ajay Khunteta is Asst Prof in CS/IT Deptt of Poornima College of Engi- ting) and multi-user features, group editors appear capa-
neering, Jaipur, Rajasthan, India.
cesses to shared objects is one of the core issues in the
design of these types of systems. Real time group editors
(e.g., Grove and Reduce ) are a category of distributed
systems that allow a group of users to edit the same doc-
ument collaboratively at the same time over a computer
network, e.g., the Internet. They are frequently used as
an effective research vehicle and model of a wide range of
distributed interactive groupware applications that fea-
ture coordinated manipulation of shared data objects.
Consistency maintenance is a critical and challenging
issue in many interactive groupware applications that
can be modeled as group editors. Due to the fact that
human users are an integrated part of the system, there
are specific requirements [1] [2]:
1.1 Operational Transformation
Over the past decade operational transformation (OT)
[4, 5, 7] has become an established method for consistency
maintenance in group editors. Compared to alternative
concurrency control methods such as locking and seriali-
zation, OT has been found uniquely promising in achiev-
ing convergence, causality and intention preservation
without sacrificing responsiveness and concurrent work
in Sun et al. [8]. The main property of OT, allowing users
to edit any part of the shared data at any time, in particu-
lar matches the vision of Bentley and Dourish [3] of de-
veloping collaborative systems as a customizable colla-
boration medium. In light of their arguments, group edi-
tors with this property do not impose any constraint on
how people use the technology. Users are allowed to use
editing. With the right single- user features (e.g., format-
ble of accommodating a variety of editing purposes, work
styles, and processes [6].
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
In Collaborative systems using OT the shared
documents are replicated at the local storage of each col-
laborating site, so editing operations can be performed at
local sites immediately and then propagated to remote
sites. Remote editing operations arriving at a local site are
typically transformed and then executed. The transforma-
tion ensures that application-dependent consistency crite-
ria are achieved across all sites. The lock-free, non block-
ing property of OT makes the local response time not sen-
sitive to networking latencies. As a result, OT is particu-
larly suitable for implementing collaboration features
such as group editing in the Web/Internet context.
Figure-1
The basic idea of OT can be illustrated by using a
simple text editing scenario as follows. Given a text doc-
ument with a string "abc" replicated at two collaborating
sites; and two concurrent operations:
O1 = Insert[0, "x"] (to insert character "x" at position
"0")
O2 = Delete[2, "c"] (to delete the character "c" at posi-
tion "2")
These generated by two users at collaborating sites 1
and 2, respectively. Suppose the two operations are ex-
ecuted in the order of O1 and O2 (at site 1). After execut-
ing O1, the document becomes "xabc". To execute O2 after
O1, O2 must be transformed against O1 to become: O2' =
Delete[3, "c"], whose positional parameter is incremented
by one due to the insertion of one character "x" by O1.
Executing O2' on "xabc" shall delete the correct character
"c" and the document becomes "xab". However, if O2 is
executed without transformation, then it shall incorrectly
delete character "b" rather than "c". The basic idea of OT is
to transform (or adjust) the parameters of an editing op-
eration according to the effects of previously executed
concurrent operations so that the transformed operation
can achieve the correct effect and maintain document
consistency.
1.1.1 Inclusion and Exclusion Transformation
Sun et al [9] distinguishes inclusion transformation (IT)
and exclusion transformation (ET) functions. The IT
82
function requires that if O1 is transformed against O2 , the
effect of executing its transformed version O1 ' (O1'= IT (O1,
O2 )) on the document state that contains the effect of O2
should be the same as the effect of executing O1 on the
document state that does not contain the effect of O2. The
ET function means that O1 is transformed against O2 (O1'=
ET (O1, O2 ))in such a way that the effect of O2 is effective-
ly excluded from O1 .
Transformation properties:
Given two operations O1 and O2 let O1'= IT (O1, O2 ) and
O2'= IT (O2, O1 ) , transformation function IT is required to
Possess the following two properties [9]:
TP1: O1 o O2'= O2 o O1'
TP2: IT(IT(O, O1 ), O2')= IT(IT(O, O2 ), O1')
TP1 ensures that if O1 ll O2, the effect of executing O1
before O2 is the same as executing O2 before O1. TP2 en-
sures that transforming any operation O along different
paths will yield the same result.
2 BACKGROUND AND RELATED WORK
To explain string operations and the basic ideas of OT,
consider a scenario in which two users, A and B, collabo-
ratively edit a shared document which includes a list of
students of a class. The document is replicated at the two
sites when the users discuss about it online. Suppose that
the list is initially "Ram" and the first position of a string
is zero. User A extends the list to "Shyam,Ram" by opera-
tion OA = insert( 0, "Shyam,"). At the same time, user B
extends the list to "Ram,Raman" by operation OB = in-
sert(3,",Raman"). The two sites diverge before their results
are merged. When A receives OB, if the operation were
executed as-is, the wrong result "Shy,Ramanam,Ram"
would yield in the list of A. The intuition of O'T [1] is to
transform remote operations to incorporate the effects of
concurrent local operations that have been executed earli-
er. In this scenario, for example, A transforms OB into a
form O'B such that O'B can be correctly executed in cur-
rent state "Shyam.Ram" of site A. Considering the fact
that A has inserted a string of six characters on the left
side of the intended position of OB, we must shift the po-
sition of OB by six to the right, yielding O'B = insert(9,
"Raman"). Execution of O'B in state "Shyam,Ram" results
in the right list of "Shyam,Ram,Raman". On the other
hand, when user B receives OA, the operation can be ex-
ecuted as-is in current state of B because the target posi-
tion of OA is not affected by the execution of OB. This re-
sults in list "Shyam,Ram,Raman". Now the two sites con-
verge.
2.1 System Model and Notations
A number of collaborating sites is there in a system.
The shared data is replicated at all sites when a session
starts. Local operations are executed immediately and for
local responsiveness, each site submits operations only to
its local replica. In the background, local operations are
propagated to remote sites. The shared data is like a li-
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
near string of atomic characters. Objects are referred to by
their positions in the string, starting from zero .It consider
two only primitive operations, namely, insert(p, s) and
delete(p, s), which insert and delete a string s at position
p in the shared data, respectively. Any operation o has
attributes like o.id is the unique id of the site that original-
ly submits o; o.type is the operation type which is
either insert or delete; o.pos is the position in the
shared data at which o is applied; o.str is the target string
which the operation inserts or deletes. For an operation o,
o.pos is always defined relative to some specific state of
the shared data.
In the following table[13] general notations of op-
eration are summarized.
83
4: o' IT(o, ol2.head)
5: ol ITLL(o'.sol, ol2.tail)
6: endif
7: return ol
Now we specify the function,ITOSq[12]. As shown in Al-
gorithm 1, function ITOSq(o,sq) transforms an operation
o with a sequence sq. To do that, we need to transform o
one by one with every operation sq[i]. However, both o
and sq[i] could be atomic or composite . To simplify
processing, we first collect all sub- operations of sq in list
ol by calling function getSubOpList(sq). Then, we use
another algorithm to transform one list o.sol with anoth-
er list ol.
The algorithm to transform two lists is imple-
mented by a double recursion of two functions, ITLL[12]
and ITOL[12]. As shown in Algorithm 2, ITLL(ol1, ol2)
transforms one list ol1 with another list ol2. In the simplest
case, if ol1 or ol2 is empty, just return ol1. Otherwise, we
divide ol1 into two parts, its first element ol1.head and the
rest of the list ol1.tail. Then we call function ITOL to trans-
form operation ol1.head with list ol2, yielding OlH, and
call function ITLL to transform list ol1.tail with list ol2,
yielding OlT. Finally, we concatenate these two partial
results, OlH and OlT, and return OlH . OlT as the result of
ITLL(ol1 , ol2). In Algorithm 3, function ITOL(o, ol2) trans-
forms an operation with a list ol2. Given a non-empty list
ol2, we need to transform o with operations in ol2 one by
one. Depending on types of the two involved operations,
we first call some IT(o, ol2.head) to transform o with the
first operation in ol2, yielding intermediate result o'; then
we call ITLL(o'.sol, ol2.tail) to transform o'.sol with the
rest of list ol2. The intermediate list o'.sol may be a single-
ton if the result is an atomic operation.

3 ALGORITHMS Algorithm 4: SITOSq(o,sq): o'

1: o'  o
3.1 Sequence-Related IT Functions 2: ol getSubOpList(sq)
3:if |o'|>1 then
4: o'.sol  SITLL(o'.sol,ol)
Algorithm 1: ITOSq(o,sq): o' 5:else
1: o'  o
6: o'.sol  SITOL(o'.sol,ol)
2: ol getSubOpList(sq)
7:endif
3: o'.sol  ITLL(o'.sol,ol)
8: return o'
4: return o'
Algorithm 5: SITLL(ol1,ol2):ol
Algorithm 2: ITLL(ol1,ol2):ol 1: if ol1=[] or ol2=[] then
1: if ol1=[] or ol2=[] then
2: ol ol1
2: ol ol1
3: else
3: else
4: olHSITOL(ol1.head,ol2)
4: olHITOL(ol1.head,ol2)
5: olT SITLL(ol1.tail, ol2)
5: olT ITLL(ol1.tail, ol2)
6: ololH.olT
6: ololH.olT
7: endif
7: endif
8: return ol
8: return ol
Algorithm 6: SITOL(o, ol2):ol
Algorithm 3: ITOL(o, ol2):ol 1: if ol2=[] then
1: if ol2=[] then
2: ol [ol]
2: ol [ol]
3: else
3: else
4: o' IT(o, ol2.head)
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
5:if |o'|>1 then
6: ol SITLL(o'.sol, ol2.tail)
7:else
8: ol SITOL(o'.sol, ol2.tail)
9: endif
10: return ol
We propose the new function, SITOSq instead of ITOSq.
As shown in Algorithm 4, function SITOSq(o,sq) trans-
forms an operation o with a sequence sq. To do that, we
need to transform o one by one with every operation
sq[i]. However, both o and sq[i] could be atomic or com-
posite operatiopns . To simplify processing, we first col-
lect all sub-operations of sq in list ol by calling function
getSubOpList(sq). Then, if o is a composite operation we
use another algorithm SITLL to transform one list o.sol
with another list ol otherwise if o is an atomic operation
then we will call directly SITOL that is a new proposed
algorithm instead of ITOL to transform one operation o
with list ol2 .
Algorithm SITLL is a bit similar to ITLL but in
STILL we have SITOL and in ITLL we have ITOL. In Al-
gorithm 5, newly proposed function SITOL(o, ol2) trans-
forms an operation with a list ol2. Given a non-empty list
ol2, we need to transform o with operations in ol2 one by
one. Depending on types of the two involved operations,
we first call some IT(o, ol2.head) to transform o with the
first operation in ol2, yielding intermediate result o'; then
if o is a atomic operation then we call SITOL to transform
a operation o'.sol with the rest of list ol2 and if o is a com-
posite operation we call SITLL(o'.sol, ol2.tail) to transform
list o'.sol with the rest of list ol2. Note that the interme-
diate list o'.sol may be a singleton, if the result is an atom-
ic operation.
3.2 Comparison
The difference between ITOSq and SITOSq is that if o
is an atomic operation then we are directly calling SITOSq
instead of at first calling SITLL and then from SITLL fur-
ther calling SITOSq step[3-6] of algorithm 4 . It get re-
sulted in reduction of runtime recursion overhead .Also
in algorithm ITOL the intermediate list o'.sol may be a
singleton if the result o' is an atomic operation. In this
algorithm also each time at step 5 ITLL is getting called
whether result o' is a composite operation or a atomic
operation .So if o is a atomic operation then we are direct-
ly calling SITOL instead of at first calling SITLL and then
from SITLL further calling SITOL in step[5-9] of algo-
rithm 6. It gets resulted in reduction of runtime overhead
of recursion what saves time.
So overhead of recursion is lesser in SITOSq and
SITOL as compared to ITOSq and ITOL.
3.3 Sequence-Related swap Functions
Algorithm 7: swapDsqD(sq,o): (o' ,sq')
1: o'o
2: ol getSubOpList(sq)
84
3:( o'.sol,ol ) swapLL(ol, o'.sol, |ol|-1)
4: sq'combineSubOpList(ol)
5:return(o' ,sq' )
Algorithm 9 : swapLO(ol1,o,p):( ol2', ol1')
1: if p=0 then
2: (o' , ol1'[0]) swapDD(ol1[0] , o)
3: return(o'.sol, ol1')
4: else
5: ol1' ol1
6: (o' , ol1'[p]) swapDD(ol1' [p] , o)
7: ( ol2', ol1') swapLL(ol1' , o'.sol, p-1)
8: return(ol2', ol1' )
9: endif
In Algorithm 7, function swapDsqD(sq,o) transposes a
deletion sequence sq and a deletion o. Swapping two
deletions may result in composite operations. We first
flatten sq into list ol, then call function swapLL[12] to
transpose list ol and list o'.sol, and finally combine sub
operations in the resulting list. When calling swapLL, the
third parameter is the index indicating from which opera-
tion in list ol we start the actual swapping. The algorithm
for transposing two lists is implemented by a double re-
cursion of two functions, swapLL and swapLO, as speci-
fied in Algorithm 7 and 9, respectively. Function
swapLL(ol1, ol2, p) transposes two given list ol1 and ol2,
where ol1  ol2, into ol1' and ol2' such that ol2' ol1' . Due
to Algorithm 7, the input ol2 is a sub operation list. That
is, operations in ol2 are defined relative to the same state.
Hence the ordering of operations in ol2 is not important.
Function swapLL works as follows: First, we call swap-
LO(ol1', ol2.head, p) to transpose ol1' with the first opera-
tion in ol2 , where ol1' is a copy of ol1. While ol1 is trans-
formed in place, operation ol2.head is transformed into
list ol2H. Then, we recursively call function swapLL(ol1',
ol2.tail, p) to transpose ol1' with the remaining operations
in ol2. Again, while ol1' is transformed in place, list ol2.tail
is transformed into list ol2T. Finally, we concatenate par-
tial results ol2H with ol2T into ol2' and return tuple (ol2',
ol1'). Because operations in ol2 are all contextually equiva-
lent, operations in the resulting ol2' are also contextually
equivalent.
Function swapLO(ol1, o, p) transposes list ol1 and
operation o, where ol1  o, into list ol1' and list ol2', re-
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
spectively, such that ol2' ol1' . Parameter p points to the
current operation in ol1 to be transposed with o. If p is
zero, we call swapDD to transpose ol1 [0] with o, yielding
ol1' [0] and o', and return the resulting o'.sol and ol1'. Oth-
erwise, we transpose every operation in ol1 with o from
right to left, as in lines 5-8. First, we call swapDD(ol1' [p],
o) to transpose the last operation in ol1' and o, transform-
ing o into o'. Note that ol1' is a copy of ol1 and all its oper-
ations are transformed in place. As a result of swapDD, o'
could be a composite operation. Hence we call
swapLL(ol1', o'.sol, p -1) to transpose ol1' with o'.sol,
which transforms o'.sol into ol2'.
Algorithm 10: MswapDsqD(sq,o): (o' ,sq')
1: o'o
2: ol getSubOpList(sq)
3: if |o'|>1 then
4:( o'.sol,ol ) MswapLL(ol, o'.sol, |ol|-1)
5: else
6:( o'.sol,ol ) MswapLO(ol, o'.sol, |ol|-1)
7:endif
8: sq'combineSubOpList(ol)
9:return(o' ,sq' )
In Algorithm 10, function MswapDsqD(sq,o) trans-
poses a deletion sequence sq and a deletion o. We first
flatten sq into list ol, then call function MswapLL or
MswapLO to transpose list ol and list o'.sol, and finally
combine sub operations in the resulting list by combine-
SubOpList(ol). When we swap two deletions may result
in composite operations. If o' is a composite operation
then we call MswapLL and if o' is an atomic operation
then we call MswapLO. The third parameter in MswapLL
and MswapLO is the index indicating from which opera-
tion in list ol we start the actual swapping. The algorithm
for transposing two lists is implemented by a double re-
cursion of two functions, MswapLL and MswapLO, as
specified in Algorithm 7 and 9, respectively. Function
MswapLL(ol1, ol2, p) transposes two given list ol1 and ol2,
where ol1  ol2, into ol1' and ol2' such that ol2' ol1' . Due
to Algorithm 10, the input ol2 is a sub operation list. That
is, operations in ol2 are defined relative to the same state.
Hence the ordering of operations in ol2 is not important.
Algorithm 11 :
MswapLO(ol1,o,p):( ol2',ol1')
1: if p=0 then
2: (o' , ol1'[0]) swapDD(ol1[0] , o)
3: return(o'.sol, ol1')
4: else
5: ol1' ol1
6: (o' , ol1'[p]) swapDD(ol1' [p] , o)
7: if |o'|>1 then
8: ( ol2', ol1') MswapLL(ol1' , o'.sol, p-1)
9: else
10:(ol2', ol1') MswapLO(ol1' , o'.sol, p-1)
11:endif
12: return(ol2', ol1' )
13: end
85
Function MswapLO(ol1, o, p) transposes list ol1
and operation o, where ol1 o, into list ol1' and list ol2',
respectively, such that ol2' ol1' . Parameter p points to
the current operation in ol1 to be transposed with o. If p is
zero, we call swapDD to transpose ol1 [0] with o, yielding
ol1' [0] and o', and return the resulting o'.sol and ol1'. Oth-
erwise, we transpose every operation in ol1 with o from
right to left, as in lines 5-8. First, we call swapDD(ol1' [p],
o) to transpose the last operation in ol1' and o, transform-
ing o into o'. Note that ol1' is a copy of ol1 and all its oper-
ations are transformed in place. As a result of swapDD, o'
could be a composite operation. Hence if | o'|>1 then we
call MswapLL(ol1', o'.sol, p -1) to transpose ol1' with o'.sol,
which transforms o'.sol into ol2' otherwise if o' is an atom-
ic operation we call MswapLO.
Algorithm MswapLL and swapLL differ only in a
way that in MswapLL we use MswapLO and in swapLL
we use swapLO.
3.4 Comparison
Algorithm MswapDsqD and algorithm MswapLO use
to call function MswapLL only when intermediate result
o' is a composite operation otherwise if o' is an atomic
operation then they directly call MswapLO instead of at
first calling MswapLL and then through MswapLL fur-
ther calling MswapLO step[3-7] of algorithm 10 and
step[7-11] of algorithm 11. In the case when o' is a atomic
operation whether we call MswapLO directly or through
MswapLL we get same output so to reduce recursion
overhead we use to call MswapLO directly in algorithm10
and algorithm 11.
On the other hand in algorithm swapDsqD and swap-
LO each time function swapLL is getting called even
when o' be an atomic operation . It increases extra over-
head of recursion when o' be atomic because at first it use
to call swapLL and then through it call swapLO but if
swapLO get called directly then also get same output.
That’s why in MswapLO and MswapDsqD the run-
time overhead of recursion is lesser than swapLO and
swapDsqD in a particular situation where intermediate
result is an atomic operation.
4. CONCLUSION
This paper proposed new algorithm like MswapDsqD,
MswapLO, SITOSq and SITOL. The algorithm like
MswapDsqD, MswapLO, SITOSq and SITOL have lesser
run time overhead of recursion as compared to
swapDsqD, swapLO, ITOSq and ITOL respectively.
All these algorithms supports string based primitive
operations and its time complexity is lesser than earlier
similar algorithms because of less number of recursion
and conditions in the algorithms.
REFERENCES
[1] C. A. Ellis and S. J. Gibbs. Concurrency control in groupware sys-
tems. In ACM SIGMOD’89 Proceedings, pages 399–407, Portland
Oregon, 1989.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 86
[2] C. Sun, X. Jia, Y. Zhang, Y. Yang, and D. Chen. Achieving conver-
gence, causality-preservation, and intention preservation in real-time
cooperative editing systems. ACM Transactions on Computer-
Human Interaction, 5(1):63–108,
[3] R. Bentley and P. Dourish. Medium versus mechanism: Supporting
collaboration through customization. In ECSCW'95 Proceedings,
1995.
[4] A. H. Davis, C. Sun, and J. Lu. Generalizing operational transforma-
tion to the standard general markup language. In ACM CSCW'02,
pages 58{67,Nov. 2002.
[5] C. A. Ellis and S. J. Gibbs. Concurrency control in groupware sys-
tems. In ACM SIGMOD'89 Preceedings, pages 399{407, Portland
Oregon, 1989.
[6] S. Noel and J.-M. Robert. Empirical study on collaborative writing:
What do co-authors do, use, and like. Journal of Computer Sup-
ported Cooperative Work, 13:63{89, 2004.
[7] C. Sun and C. Ellis. Operational transformation in real-time group
editors: issues, algorithms, and achievements. In ACM CSCW'98,
pages 59{68, Dec. 1998.
[8] C. Sun, X. Jia, Y. Zhang, Y. Yang, and D. Chen. Achieving conver-
gence, causality-preservation, and intention-preservation in real-time
cooperative editing systems. ACM Transactions on Computer-
Human Interaction , 5(1):63{108, Mar. 1998.
[9] C. Sun, X. Jia, Y. Zhang, Y. Yang, and D. Chen. Achieving conver-
gence, causality-preservation, and intention- preservation in real-
time cooperative editing systems. ACM Transactions on Computer-
Human Interaction, 5(1):63–108, Mar. 1998.
[10] C. A. Ellis and S. J. Gibbs. Concurrency control in groupware sys-
tems. In Proceedings of the ACM SIGMOD'89 Conference on Man-
agement ofData, pages 399-407, Portland Oregon, 1989.
[11] C. Sun and C. Ellis. Operational transformation in real-time group
editors: issues, algorithms, and achievements. In Proceedings of the
ACM Conference on Computer-Supported Cooperative Work, pages
59-68, Dec. 1998.
[12] ABTS : A Transformation-Based Consistency Control Algorithm for
Wide-Area Collaborative Applications Bin Shao , Du Li , Ning Gu .
School of Computer Science, Fudan University, Shanghai, China.
Nokia Research Center, Palo Alto, California, USA Digital Object
Identifier: 10.410B/ ICST.COLLABORATECOM 2009. B271
[13] C. Sun and C. Ellis. Operational transformation in real-time group
editors: issues, algorithms, and achievements. In Proceedings of the
ACM Conference on Computer-Supported Cooperative Work, pages
59-68, Dec. 1998.