See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/310212186

Near Real-Time Peer-to-Peer Shared Editing on

Extensible Data Types

Conference Paper · November 2016

DOI: 10.1145/2957276.2957310

CITATION READS

1 331

4 authors, including:

Petru Nicolaescu Michael Derntl

RWTH Aachen University University of Tuebingen
25 PUBLICATIONS 80 CITATIONS 122 PUBLICATIONS 1,047 CITATIONS

SEE PROFILE SEE PROFILE

Ralf Klamma
RWTH Aachen University
327 PUBLICATIONS 2,069 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ConProMa View project

Learning Layers project (2012 -2016) - Construction sector pilot and follow-up View project

All content following this page was uploaded by Petru Nicolaescu on 14 November 2016.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
This is the authors' preprint of a paper to appear in the Proceedings of the 19th
International Conference on Supporting Group Work (GROUP 2016) © Copyright 2016 ACM

Near Real-Time Peer-to-Peer Shared Editing on Extensible

Data Types

Petru Nicolaescu Kevin Jahns Michael Derntl

RWTH Aachen University RWTH Aachen University Eberhard Karls Universität
Lehrstuhl Informatik 5 Lehrstuhl Informatik 5 Tübingen eScience-Center
Ahornstr. 55 Ahornstr. 55 Wilhelmstr. 32
52074 Aachen, Germany 52074 Aachen, Germany 72074 Tübingen, Germany
[email protected] [email protected] michael.derntl@uni-
aachen.de aachen.de tuebingen.de
Ralf Klamma
RWTH Aachen University
Lehrstuhl Informatik 5
Ahornstr. 55
52074 Aachen, Germany
[email protected]
aachen.de

ABSTRACT CCS Concepts

Near real-time collaboration using Web browsers is becom- •Human-centered computing → Collaborative and
ing rapidly more and more popular for many applications social computing; Computer supported cooperative
such as text editing, coding, sketching and others. These ap- work; Collaborative and social computing systems
plications require reliable algorithms to ensure consistency and tools; Synchronous editors; Collaborative interac-
among the participating Web clients. Operational Trans- tion; Open source software; •Computing methodologies
formation (OT) and more recently Commutative Replicated → Concurrent algorithms;
Data Types (CRDT) have become widely adopted solutions
for this kind of problem. However, most existing approaches
are non-trivial and require trade-offs between expressiveness,
Keywords
suitable infrastructure, performance and simplicity. The Near real-time collaborative editing; commutative replicated
ever growing number of potential use cases, the new possi- data types; operational transformation; peer-to-peer infor-
bilities of cutting-edge messaging protocols that shaped the mation systems
near real-time Web, and the use of N-way communication
between clients (e.g. WebRTC), create a need for peer-to- 1. INTRODUCTION
peer algorithms that perform well and are not restricted
Near real-time (NRT) collaboration techniques have been
to only a few supported data types. In this paper, we
intensively studied by the CSCW community during the past
present YATA, an approach for peer-to-peer shared editing
three decades [6, 30, 26, 29]. Mostly directed towards shared
applications that ensures convergence, preserves user inten-
editing, highly relevant works include OT [6] algorithms and
tions, allows offline editing and can be utilized for arbitrary
systems for enabling concurrent editing on the Web. These
data types in the Web browser. Using Yjs, its open-source
approaches leverage optimistic and reliable concurrency con-
JavaScript library implementation, we have evaluated the
trol mechanisms that lead to widely adopted OT-based sys-
performance and multiple usage of YATA in Web and mobile
tems such as Google Docs. A major advantage is that these
browsers, both on test and real-world data. The promising
systems do not require any locking mechanisms to ensure
evaluation results as well as the uptake by many commercial
consistency of the shared data [10]. In a NRT setting, the
vendors and open-source projects indicate a wide applicabil-
user agents apply edits immediately to their local copy, while
ity of YATA.
concurrently sending notifications of those changes via com-
munication protocols to the remote user agents. All copies
have to eventually have the same content, regardless of the
order of the received operations or problems that might oc-
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed cur during the message propagation, such as temporary con-
for profit or commercial advantage and that copies bear this notice and the full cita- nection loss.
tion on the first page. Copyrights for components of this work owned by others than Recent advances on the Web allowed the development
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-
publish, to post on servers or to redistribute to lists, requires prior specific permission of fast and reliable communication protocols, such as We-
and/or a fee. Request permissions from [email protected]. bRTC, Websockets, XMPP over Websockets, Server-Sent
GROUP ’16, November 13-16, 2016, Sanibel Island, FL, USA Events, which were also quickly adopted by Web commu-
c 2016 ACM. ISBN 978-1-4503-4276-6/16/11. . . $15.00 nities, industry and academia. Besides enabling the mes-
DOI: http://dx.doi.org/10.1145/2957276.2957310 sage propagation technology stack required for shared edit-
ing systems, such protocols can leverage the use of peer-to- sider it to be very promising for leveraging lightweight appli-
peer (P2P) shared editing algorithms and offer a fast and cations, where collaboration logic can be easily engineered
reliable communication infrastructure for their implementa- on the client side. Finally, besides the usage in real-world
tions. Thus, P2P approaches became a viable alternative open-source products, Yjs has been thoroughly evaluated in
to the more traditional client-server approaches [3]. This is a simulated distributed environment for performance, test-
due to the fact that each collaborator receives the updates in ing the conflict resolution and its scalability, with very good
a N-way communication and applies them locally, without results.
the need to wait for acknowledgment data, orders or trans- The rest of this paper is organized as follows. First, in
formed operations from a central server. In consequence, Section 2 we give a short introduction to consistency main-
existing NRT collaboration algorithms need to adapt to new tenance algorithms, their development within the CSCW
performance requirements, which is not a trivial task, espe- community and describe their most relevant features. Sec-
cially in the case of massive collaboration, with a scaling tion 3 describes the YATA approach, offers a formal proof
number of users and changes [20]. that it converges regardless of the number of peers involved
With few exceptions, available OT algorithms are designed in collaboration and presents a time and space complexity
for client-server architectures. Algorithms that do support analysis. Furthermore, we offer the details for extending
N-way P2P message propagation still rely on propagating a the approach to other data types in Section 4. Section 5
state vector (e.g., COT [29]) with each message. Moreover, shortly describes the Yjs framework. The consistency tests
algorithms that need preprocessing on the server side cannot performed for our approach and the usage of the framework
be used in such P2P settings. In the past decade, CRDT in real applications are presented in Section 6. Finally, Sec-
algorithms [20, 2, 21, 23] emerged in the distributed sys- tion 7 summarizes the main contributions and provides an
tems specialization area and were also used in collaborative outlook for this work.
editing [1]. These have a small document update size and
do not rely on vector clocks (e.g., the WooT approach [20]), 2. RELATED WORK
and can therefore suit the new communication protocols and
Previous studies present various techniques for solving
practices on the Web. A short comparison of the different
conflicts in collaborative editing settings. Coined during
algorithms is given in Section 2.
late 1980s, concurrency control [6, 27] includes locking (pes-
Regardless of being P2P or a client-server approach, the
simistic, mutually exclusive mechanism), transactions, sin-
available NRT collaboration tools (e.g. OT-based) mostly
gle active participation (token-based participation), depen-
support linear data or other specific ones (e.g. tree-like [11])
dency detection (timestamps for conflict detection), differen-
for ensuring the above described properties. Applications
tial synchronization (client-server asynchronous approach)
based on complex models must therefore map the under-
[7] and three-way merge (classic versioning systems).
lying data to the data structure that is supported by the
The most prominent mechanisms for optimistic concur-
used collaboration framework. However, this process is time
rency control are OT [6, 26, 27, 28] and CRDT [20, 21, 31,
consuming, application-specific, and often hard to achieve.
23]. OT algorithms distinguish between a control algorithm
Moreover, there are few open-source implementations that
and a transformation function [28]. The former determine
work directly in Web browsers, can be used P2P and of-
the concurrent operations to be transformed against other
fer a developer-friendly, easy and intuitive way for rapidly
operations according to concurrency/context relations. The
enabling NRT collaboration on custom data types.
latter determine how to transform a pair of operations ac-
To overcome these shortages of existing algorithms, we
cording to their type, position and other parameters. The
present a new approach called YATA (Yet Another Trans-
responsibilities of these two components are defined by a set
formation Approach) for enabling NRT collaboration on ex-
of transformation properties and conditions. An overview of
tendable data types and Yjs, its open-source implementa-
OT control algorithms, their verification and available state
tion. We have developed an efficient algorithm that ensures
of the art systems are given in [28, 32, 17, 13]. In contrast,
the convergence and intention preservation for collaboration
CRDT algorithms offer optimistic concurrency control by
on shared data types. By design YATA inherently leads
defining commutative operations that do not conflict with
to fewer conflicts, exposes a favorable run time complexity,
each other [24]. In the following, we provide a brief selec-
supports offline editing (i.e. given a peer that is joining the
tion of relevant OT and CRDT algorithms.
collaboration session with unsynchronized changes) and col-
The Google OT approach for Google Wave/Google Docs
laboration on various data types. The algorithm uses an
[32] is based on the Jupiter approach [18]. In both cases the
internal linked list representation, similar to the CDRT ap-
server has to preprocess operations before one is executed
proaches WooT [20] and WooTH [1]. However, as it has been
and propagated to all clients. There is no direct communi-
proven that keeping deleted operations leads to a loss of per-
cation between clients. Similarly, the client also preprocesses
formance, YATA solves this disadvantage by introducing a
received operations before it executes them. Since the client
garbage collector for avoiding a drastic increase of unneces-
has its own history buffer, it can use the same preprocessing
sary operations.
algorithm as the server. Generalized OT (GOT) [27], GOT
For exploiting YATA in Web applications, the algorithm
Optimized (GOTO) [26] and AnyUndo [25] are algorithms
was implemented as an open-source framework called Yjs1
that do not depend on a server that preprocesses operations.
[19], which can be used with multiple communication proto-
The AnyUndo OT algorithm extends GOTO with undo ca-
cols, including P2P, federated or client-server. By means of
pabilities, while reusing its transformation algorithm. The
Yjs, which is already garnering interest from the open-source
space complexity of this algorithm is nearly as good as the
community, we have observed YATA’s performance and con-
Jupiter approach, but its time complexity can be quadratic.
Moreover, it has been shown that the GOTO and AnyUndo
1
http://y-js.org approaches work if there are transformation functions that
fulfill CP1 [22] and CP2 properties [22]. Sun et al. [28] de- was developed for linear data, extended with an undo mech-
scribe these transformation properties—correctness criteria anism based on a PN-Counter [31, 24]. It does not require
used in OT literature, needed to achieve convergence (CP1, tombstones, which makes the algorithm more efficient com-
CP2). Violations of these properties result in inconsistent pared to similar mechanisms such as WooT.
replicas of a shared document. Similar to GOTO/AnyUndo,
the Context-based OT (COT) [30] algorithm does not need
server-side preprocessing. Furthermore, the algorithm en- 3. THE YATA APPROACH
ables direct communication between the clients. The idea The YATA approach is created to provide a scalable solu-
behind COT is to save every received operation “as is” in a tion for P2P optimistic concurrency control on the Web. The
document state and preprocess it afterwards given the op- main goals are to allow the P2P collaborative editing of Web
eration context. COT has a simplified design, as only one pages (DOM elements), graphs, lists, objects and arbitrary
transformation function must be defined. The downside of types in the Web browser, using cutting-edge protocols for
this approach is that a state vector must be transmitted message propagation. Therefore, the algorithm proposes a
with every operation, where the size of the state vector is basic structure using a linked list, which can be extended to
proportional to the number of users in a collaborative ses- achieve collaboration on new shareable data types. YATA’s
sion. The Time Interval Based Operational Transformation linked list internal representation and a collection of prede-
(TIBOT) approach sends operations to all other clients in fined rules limit the number of possible conflicts and ensure
an N-way communication model. However, each client is intention preservation and convergence. The core idea is
only allowed to send the operations at a certain time inter- enforcing a total order on the shared data types. YATA
val [16]. This significantly reduces complexity, for the price also supports offline editing, being meant to cope with re-
that updates may take longer to be processed. Similarly, quirements coming from both Web and mobile clients, such
the successor approach TIBOT2 maintains a distributed to- as small operation updates for low bandwidth, on and off
tal ordering schema on the execution sequence of operations, connections, random message order at receive time, etc.
allowing N-way communication between clients. Moreover, YATA currently supports collaboration on linear data,
it avoids both CP1 and CP2 [32] via a more efficient remote trees, associative arrays and graphs. Using those types, it is
processing approach. possible to create more complex data types.
All in all, OT approaches still have several drawbacks, In the following we formalize our approach and exem-
such as scaling problems in peer-to-peer and cloud networks plify YATA’S behavior on text (linear data). After giving
with dynamic (join/leave) user behavior [1] and a high com- the assumptions, definitions and describing how convergence
plexity in solving convergence. This is a reason why most is achieved, we extend the linear representation to more
OT implementations [13] are restricted to linear data struc- data types and explain how those are further realized us-
tures or specific ones, such as tree-like [9, 4, 11, 12]. More- ing YATA.
over, the complexity was a reason for slowing down the
spread of collaborative applications on the Web, which flour- 3.1 Requirements
ished with the uprise of Google and cloud-based systems. Unique identifiers. Each user is represented by an unique
On the other side, CRDT systems are designed for peer- identifier (userid). Additionally, each user gets an operation
to-peer environments and to perform and achieve consis- counter which gets incremented every time a user creates
tency for a big number of users. They can be state-based an operation. Upon its creation, the operation thus gets as-
or operation-based [24]. Without OT (WooT) [20] is an ap- signed a unique identifier which is composed of the userid
proach built for consistency preservation in P2P systems. and the current operation counter.
It uses a monotonic linearization function to ensure conver- Operations. YATA represents linear data (e.g. text) as
gence as a solution to topological sort. According to [20], a doubly linked list. We define only two types of changes
WooT supports linear structures, lists, block of texts and or- on this representation: insert and delete. As it is shown in
dered trees. It generates partial orders for operations, which Figure 1, every element in the linked list is represented by
are represented as elements and assigned a unique identifier. an insert operation (also named insertion). When an inser-
Moreover, it makes use of an unique identifier for each col- tion is deleted, it is just marked as such and not removed
laborating site and one for each operation, a value for the from the list (i.e. tombstone approach). Therefore, delete
effect of an operation and the identifiers of previous and operations do not have an effect on our insert algorithm. In
next operations for each given “character value” of an in- Section 3.5 we define a garbage collection mechanism that,
sert operation. WooT uses tombstones (i.e. no elements are in combination with our insert algorithm 3.4, can remove
deleted, they are only marked for deletion), which means deleted insertions.
that operations are not deleted. Each site maintains be-
sides the identifier a logical clock, a sequence for character
values and a structure for pending operations. Similar to )
YATA, WooT was designed to work in a P2P architecture
and it is independent from the order of reception of oper- lef
t (=o
rigin
T
onew ?
rig
ht

ations. WooTO and WooTH [1] improve the WooT algo-

rithm in terms of performance [1], via a linked list and a
hash table for optimizing retrieval, update and insertion of
operations. They were inspired by the replicated growing
array (RGA) approach [23, 1], which introduced update op-
Y
o
A
o
1 2
To
3
A
o 4
!o
5
erations in addition to the classic insertions and deletions.
Lagoot [31] provides a totally-ordered set of elements and Figure 1: Integration example on text (linear) type.
 We denote an insert operation as ok (idk , origink , lef tk , conflicts with c1 ..cn .
rightk , isDeletedk , contentk ), where idk is ok ’s unique iden- In the following we define a function <c that specifies a
tifier, contentk is the content (e.g. a character), isDeletedk position for onew in the set of conflicting insertions (c1 ..cn ).
is a flag that marks an insertion as deleted, and origink , As such onew is integrated between ci , and ci+1 when ci <c
lef tk , rightk are references to other already existing inser- onew <c ci+1 . Furthermore, we show that every site con-
tions. We represent linear data as a doubly linked list S verges when integrating with <c (i.e., we prove that <c is a
of insertions. Therefore, lef tk , and rightk reference to the strict total order function).
previous node, respectively next node in the list. origink de- In the following we will frequently refer to the graphical
notes the direct predecessor at creation time (i.e., the node representation of insertions as it is shown in Figure 1. The
after which it was originally integrated to). insertion onew has three references/connections. On the left
We define < as the natural predecessor relation on S. hand site of onew there is a originnew connection, and a
lef tnew connection to o1 . On the right hand site of onew
o1 < o 2 ⇔ o1 is a predecessor of o2 (1) there is a rightnew connection to o4 . While lef tnew , and
o1 ≤ o2 ⇔ o1 < o 2 ∨ o1 ≡ o2 (2) rightnew define the usual predecessor/successor relation in
a linked list. The originnew connection will never change
Example. When a user creates a new insertion at a lo-
and is employed to find the strict total order function <c .
cal site, this is integrated between two insertions oi , and
We compose the following three rules in order to find a
oj . The newly created insertion is therefore defined as:
strict total order <c on conflicting operations.
onew (idk , oi , oi , oj , f alse, contentnew ). Note that lef tnew ,
and rightnew are defined when an insertion has been ap- Rule 1 We forbid crossing of origin connections (red lines
plied to the list and may change when new insertions are in the graphical representation) between conflicting inser-
integrated into S, but originnew , defined at insertion cre- tions. This rule is easily explained using the graphical rep-
ation time is never modified. After the user integrates a resentation of insertions in the linked list. As we stated
new insertion at his local site he sends it (via broadcast), as before, every insertion has an origin connection to an in-
is, to all users. sertion to the left (to a predecessor). Only when two op-
A special case occurs when an insertion is performed at the erations are concurrently inserted after the same insertion,
beginning or at the end of S, because there is no insertion to they will have the same origin.
refer to as lef t∗ , respectively right∗ . This can be fixed by
using special delimiters, which denote the beginning and
the end of S, respectively. Therefore, we assume without Y A T A ! Y A T A !
loss of generality that an insertion always defines origink ,
lef tk , and rightk .
Figure 2: No line crossing.
3.2 YATA
The example in Figure 1 shows how a received operation Figure 2 illustrates the two cases that are allowed when
onew is integrated in S. Here, the red connections refer- line crossing is forbidden. Either, one operation is between
ence the intention of the insertion, which is defined through the other operation and its origin, or the origin of the one
lef tnew and rightnew - i.e. insert the letter between these operation is a successor of the other operation. Therefore,
two letters. When the insertion is integrated, YATA as- the following formula must hold for conflicting insertions
sures that it will be placed somewhere between these letters. o1 and o2 :
Convergence is therefore ensured, unless one or more re- o1 <rule1 o2 ⇔ o1 < origin2 ∨ origin2 ≤ origin1 (3)
mote operations were already inserted between lef tnew and
rightnew , which then leads to a conflict that needs to be Rule 2 Specifies transitivity on <c . Let o1 <c o2 . Then
solved. following rule ensures, that there is no o that is greater
Definition: Intention Preservation. than o2 , but smaller than o1 , with respect to <c
The intention of an insertion oi is preserved if and only o1 <rule2 o2 ⇔ ∀o : o2 <c o → o1 ≤ o ⇔ @o : o2 <c o < o1
if the insertion is integrated somewhere between lef ti and (4)
righti . This notion of intention preservation conforms to
the natural perception for the intention of text insertions Rule 3 When two conflicting insertions have the same ori-
and it is similar to other definitions found in the literature. gin, the insertion with the smaller creator id is to the left.
In [2], the intention preservation is defined when each char- We borrow this rule from the OT approach. But in OT this
acter inserted by a user between two other characters in a rule is applied when the position parameters are equal.
document keeps its relative position between its neighbors o1 <rule3 o2 ⇔ origin1 ≡ origin2 → creator1 < creator2
during the editing process. (5)
The concurrent insertion problem.
In the example in Figure 1, the intention of the insertion We get retrieve the total order function <c by enforcing all
of “T” is that should be inserted between the characters “Y” three rules:
and the “A” - e.g., at creation time, “T” sees only “YA”. o1 <c o2 ⇐⇒ o1 <rule1 o2 ∧ o1 <rule2 o2 ∧ o1 <rule3 o2
However, a letter sequence “AT” has been already inserted
⇔ o1 < origin2 ∨ origin2 ≤ origin1
between these two letters. In the example, o2 , and o3 conflict
with onew . ∧ @o : o2 <c o < o1
Definition: Conflicting insertions. ∧ origin1 ≡ origin2 → creator1 < creator2
Keeping the above notations, assuming o1 ≤c o2 ⇔ o1 <c o2 ∨ o1 ≡ o2 (6)
S = lef tnew · c1 · c2 · .. · cn · rightnew , then we say that onew
3.3 Correctness
<c only depends on the origin∗ connection, and we spec- o1 <c o2 ∧ o2 <c o3
ified above, that origin∗ never changes. We can conclude Rule 2
that whenever two sites compare conflicting insertions, they ⇒ (∀o : o2 <c o → o1 ≤ o) ∧ (o2 <c o3 )
will find the same order for insertions. Furthermore, this ⇒ (o2 <c o3 → o1 ≤ o3 ) ∧ (o2 <c o3 )
implies that all sites will eventually converge. Finally, we ⇒ o1 < o 3
prove that <c is a strict total order function, i.e. ≤c is a
total order on conflicting operations. Therefore, we have to ⇔ o1 <c o3
show that for all conflicting insertions o1 , o2 , and o3 the Proof totality. Let o1 , o2 be insertions, with o1 6= o2 .
ordering function ≤c is antisymmetric, transitive, and total. Totality is fulfilled if the following statement holds:

o1 ≤c o2 ∧ o2 ≤c o1 ⇒ o1 ≡ o2 (antisymmetry) (7) o1 <c o2 ∨ o2 <c o1 ⇐ true

o1 ≤c o2 ∧ o2 ≤c o3 ⇒ o1 ≤c o3 (transitivity) (8) if and only if
o1 ≤c o2 ∨ o2 ≤c o1 (totality) (9) ¬(o1 <c o2 ∨ o2 <c o1 ) ⇒ f alse
Proof antisymmetry. Let o1 , and o2 be insertions, with When we apply the ordering relation (6) we get the for-
o1 ≤c o2 ∧ o2 ≤c o1 . mula in Figure 3 and show for each case that totality is
Case 1: (origin1 ≡ origin2 ): fulfilled.
Case 1 (origin1 ≡ origin2 and creator1 < creator2 ):
o1 ≤c o2 ∧ o 2 ≤c o1 First steps are depicted in Figure 3
6
⇒ (o1 <c o2 ∧ o2 <c o1 ) ∨ o1 ≡ o2 ⇒ ∃o2 < o < o1
Rule 3
⇒ (creator1 < creator2 ∧ creator2 < creator1 ) ∨ o1 ≡ o2 ⇒ o2 < o 1
Rule 3
⇔ o1 ≡ o 2 ⇒ f alse

The reasoning here is that the user id has a total ordering. Case 2 (origin1 ≡ origin2 and creator2 > creator1 ):
Case 2: (origin1 < origin2 ): Similar to case 1.
Case 3 (origin1 < origin2 ):
o1 ≤c o2 ∧ o2 ≤c o1
⇔ (o1 ≤ o2 ∧ o2 ≤ o1 ) ∧ (o1 ≤c o2 ∧ o2 ≤c o1 ) Figure 3
⇔ (o1 ≤ o2 ∧ o2 ≤ o1 ) ∧ (o1 ≡ o2 ∨ (o1 <c o2 ∧ o2 <c o1 )) ⇒ (¬(o1 < origin2 ) ∨ (∃o : o2 < o < o1 ))
Rule 1
⇒ o1 ≤ o2 ∧ o2 ≤ o1 ∧(∃o : o1 < o < o2 )
∧ o1 ≡ o2 ∨ ((o1 < origin2 ∨ origin2 ≤ origin1 ) ⇔ (¬(o1 < origin2 ) ∧ (∃o : o1 < o < o2 ))
| {z }
f alse ∨(∃o : o2 < o < o1 ∧ ∃o : o1 < o < o2 )
∧(o2 < origin1 ∨ origin1 ≤ origin2 )) ⇒ (¬(o1 < origin2 ) ∧ (∃o : o1 < o < o2 ))
| {z }
true ∨(o2 < o1 ∧ o1 < o2 )
⇒ o1 ≤ o2 ∧ o2 ≤ o1 ∧ (o1 ≡ o2 ∨ o1 < origin2 ) antisymmetry
⇒ ¬(o1 < origin2 ) ∧ (∃o : o1 < o < o2 )
⇒ (o1 ≤ o2 ∧ o2 ≤ o1 < origin2 ) ∨ o1 ≡ o2
!
⇒ origin2 ≤ o1 ∧ o1 < o2
origin2 <o2 assumption
⇒ o1 ≡ o2 ⇒ origin1 < origin2 ≤ o1 ∧ o1 < o2
⇒ origin1 < origin2 ≤ o1 < o2
Case 3: (origin2 < origin1 ): Similar to Case 2. o1 and o2 conflict
⇔ origin1 < origin2 < o1 < o2
Rule 1
⇒ f alse
Proof transitivity. Let o1 , o2 , and o3 be insertions,
with o1 ≤c o2 ∧ o2 ≤c o3 , o3 conflicts with o1 , and w.l.o.g. Case 4 (origin2 < origin1 ): Similar to Case 3.
o1 6= o2 6= o3 .

¬(o1 <c o2 ) ∧ ¬(o2 <c o1 )

⇔ ¬((o1 < origin2 ∨ origin2 ≤ origin1 ) ∧ (@o : o2 <c o < o1 ) ∧ (origin1 ≡ origin2 → creator1 < creator2 ))
∧ ¬((o2 < origin1 ∨ origin1 ≤ origin2 ) ∧ (@o : o1 <c o < o2 ) ∧ (origin2 ≡ origin1 → creator2 < creator1 ))
⇔ (¬(o1 < origin2 ) ∧ ¬(origin2 ≤ origin1 )) ∨ (∃o2 <c o < o1 ) ∨ (origin1 ≡ origin2 ∧ ¬(creator1 < creator2 ))
∧ (¬(o2 < origin1 ) ∧ ¬(origin1 ≤ origin2 )) ∨ (∃o1 <c o < o2 ) ∨ (origin2 ≡ origin1 ∧ ¬(creator2 < creator1 ))
⇔ (¬(o1 < origin2 ) ∧ ¬(origin2 ≤ origin1 )) ∨ (∃o2 < o < o1 ) ∨ (origin1 ≡ origin2 ∧ ¬(creator1 < creator2 ))
∧ (¬(o2 < origin1 ) ∧ ¬(origin1 ≤ origin2 )) ∨ (∃o1 < o < o2 ) ∨ (origin2 ≡ origin1 ∧ ¬(creator2 < creator1 ))

Figure 3: Derivation of totality on (6).

3.4 Insert Algorithm In practice, YATA uses two buffers for garbage collection,
Previously, we proved that there exists a total order rela- to ensure that list elements are not directly removed. As
tion on conflicting insertions. In this section we show how such, once ok can be garbage collected, it will be moved into
we can compute the new position for an insertion, when we the first buffer. If nothing changes, after t seconds it will
already have an ordered list of insertions. be copied into the second array and from here will be re-
Listing 3.4 shows how the conflicting insertion can be moved by the garbage collector (i.e., can be safely removed
solved algorithmically. The algorithm exploits property (3) from the list and the buffer). From our practical experi-
(no line crossing) as a breaking condition. Therefore, we ences and the use in production, such a delay is sufficient
stop computing when origin connections definitely will cross. to ensure that content will be removed safely, without any
The worst case time complexity of the algorithm is O(|C|2 ) losses that may lead to inconsistencies. This is in line with
where |C| is the number of conflicting operations. In the case experiments performed for assessing the NRT criteria and
that the breaking condition is reached in the first iteration, measuring the time in which operations are being applied.
no positions are compared. This is why the best case time These experiments (cf. Figure 9, Section 6) show that the
complexity is O(1). A complexity analysis is presented in average time for receiving and applying a remove operation
Section 3.7. using text (with a length under 103 characters) at a remote
site is approx. 12 ms. Under the same conditions, receiving
and applying a single remove operation with a length of 105
// I n s e r t ’ i ’ i n a l i s t o f characters at a remote site is done within an average time
// c o n f l i c t i n g o p e r a t i o n s ’ ops ’ . of 39.3 ms (SD 2.45 ms), from a pool of ten measurements.
i n s e r t ( i , ops ) { As a consequence of YATA’s rules, in some cases it is not
i . p o s i t i o n = ops [ 0 ] . p o s i t i o n possible to remove insert operations. The reason is that for
f o r o i n ops do an operation that is inserted between two undeleted insert-
// Rule 2 : type operations, this could lead to a deleted predecessor or
// Se arch f o r t h e l a s t o p e r a t i o n successor (cf. Figure 4).
// t h a t i s t o t h e l e f t o f i .
if (o < i . origin
OR i . o r i g i n <= o . o r i g i n )
Word
AND ( o . o r i g i n != i . o r i g i n
OR o . c r e a t o r < i . c r e a t o r ) do
// r u l e 1 and 3 :
D Y A T A ! D
// I f t h i s f o r m u l a i s f u l f i l l e d ,
// i i s a s u c c e s s o r o f o . ?
i . position = o . position + 1 Y
e l s e do
i f i . o r i g i n > o . o r i g i n do Figure 4: Insertion between deleted characters.
// B r e a k i n g c o n d i t i o n ,
// Rule 1 i s no l o n g e r s a t i s f i e d In order to ensure consistency, YATA demands that a
// s i n c e o t h e r w i s e o r i g i n new insertion is always inserted between the most left non-
// c o n n e c t i o n s would c r o s s . deleted character and its direct successor. Only then, the
break garbage collector can remove all operations that are to the
} right of the first deleted insertion.
Furthermore, due to its design, the garbage collector in
YATA may break late join mechanisms. This is because
3.5 Garbage Collection when a user is offline for a period longer than t seconds,
In the literature, garbage collection has been also pro- it will still hold references to deleted operations, while on-
posed in [21] where “cold” areas of a document are identi- line users who already performed certain removals do not.
fied or in Logoot [31], which uses a graveyard for removed Therefore, YATA does not support garbage collection for a
operations. Conceptually, an insertion marked for deletion site while it is offline.
can be garbage collected when all sites received the remove
operation and have in their internal representation the op- 3.6 Ofline Editing Support
eration that is to be garbage collected. However, it is hard YATA supports offline editing using the internal data rep-
to determine if all collaborators know simultaneously that resentation which is maintained at each client. Once clients
a content was deleted. Ideally, using classic methods such are online, YATA performs a check for diverged states of the
as state vectors, a mechanism where YATA ensures that all shared data and synchronizes it.
sites have applied a removal can be a candidate solution. As Every site holds a state vector. It saves the next expected
a downside, such a mechanism would require more network operation id per user. As an example, consider user1 with
resources and leads to a decrease in performance, especially userid 1 is in a session with user2 with userid 2. Both users
in P2P settings. An optimal solution to this issue is still created two operations. As we explained above, the opera-
being considered. tion id is defined as a tuple of userid and operationcounter.
In the current approach, the problem is simplified by as- Therefore, the state vector is expressed as:
suming that all users retrieved a certain remove operation [(1, 2), (2, 2)] (assuming we start counting with 0).
after a fixed time period t which can be set according to the For synchronization, the state vector is not sent with each
expected protocol and network characteristics (e.g., 30 s). operation, but it is sent only once to all clients. A user that
receives a state vector compares it with the local state vec- require the user to send a path-vector with each oper-
tor and sends all remaining operations to the synchronizing ation. This usually has the length of the depth of the
client. In order to make operations integrable on the remote changed element, which is not necessary in YATA.
instances, operations are sent in the order and the form in
which they were created. Our YATA’s implementation can • It is possible to define many data types.
transform integrated operations to their original form.
4. EXTENDABLE TYPES
3.7 Complexity Analysis This section describes some of the basic operation types
The complexity of YATA depends on the retrieval effi- and the general data structures which YATA supports. Build-
ciency of insertions. As such, the retrieval of a specific oper- ing on top of the data structures, one can implement certain
ation can be efficiently implemented using a balanced tree, abstract data types and thus enable collaboration on com-
which exposes time complexities of O(log(H)) for insertion mon data formats such as JSON and XML. The supported
and retrieval. Here, H denotes the number of all applied types currently include linear data types (e.g., arrays, linked
operations in the balanced tree implementation. The best lists, sorted arrays, bitmaps), trees, graphs and associative
case time complexity for applying an operation is O(log(H)) arrays.
- i.e. there are no conflicting operations. The worst case
time complexity is O(log(H) + C 2 ) and only depends on the 4.1 List Manager Operation
amount of conflicting operations (C). A comparison with A List Manager (cf. Figure 5) is an abstract operation
other CRDTs performance, adapted from [1] is depicted in type that manages insert operations. It basically handles
Table 1. In this comparison, H the total number of opera- two delimiters that denote the beginning and the end of the
tions that affect a shared document. list, as exemplified in the algorithm’s description. Hence,
new insertions are placed somewhere between these delim-
LOCAL REMOTE iters according to YATA’s rules.
CRDT
INS DEL INS DEL
List Manager
WooT O(H 3 ) O(H) O(H 3 ) O(H)

WooTO O(H 2 ) O(H) O(H 2 ) O(H) D Y A T A ! D

O(H · O(H ·
Logoot O(H) O(1)
log(H)) log(H))
Figure 5: Illustration of the List operation type.
RGA O(H) O(H) O(H) O(log(H))
The List Manager operation also handles how to address
YATA O(log(H)) O(log(H)) O(H 2 ) O(log(H))
the elements in the associative list and how to transform it
to a certain data type (e.g. String). It represents linear data
Table 1: Worst case time-complexity analysis, structures such as lists and arrays, but it can also be used
adapted from [1]. in order to represent tree-like data structures. In this case,
the trees are achieved by allowing the content of insertions
to contain in their turn List Managers.
Discussion As it can be observed, compared to classical
CRDT tombstone approaches (such as WooT or WooTO), 4.2 Replace Manager Operation
YATA has a better time complexity. As expected, non- YATA supports only insert and delete operations. How-
tombstone approaches (such as Logoot of RGA) output a ever, when dealing with more complex types, update opera-
better time complexity for some operation types. Regard- tions are also required in order to ease the development. As
less of the complexity, YATA offers an approach for client- such, YATA supports updates of existing content by offer-
side conflict resolution, which is not common among existing ing a dedicated type which enables content replacement. A
CRDTs. It proposes a simple data type that can be used to Replace Manager (cf. Figure6 handles the replace function-
compose more complex ones (cf. Section 4). In Section 6, ality. As a basic example, consider the case where two users
we show that YATA’s implementation fulfills NRT scenarios (with user ids 1 and 2) concurrently replace the number 0
and give an overview on its usage performance. in a text with their respective user id. In order to keep con-
A downside of the YATA approach is that when each char- sistency, each site should reflect the replace operation and
acter is represented as an operation, the space complexity is reach the same content, i.e. either 1 or 2 will replace the
O(|D|), where |D| is the size of the shared document. In OT old number 0. YATA solves this problem by transforming
for example, it is possible to have an empty history buffer, it into an already solved problem, using data types which
when garbage collection is enabled. ensure consistency.
However, YATA outputs the following advantages over OT
approaches:
Replace Manager

• Time-complexity: YATA reduces time to synchronize, content

when late join is supported. D D

• The size of propagated messages is small: there are
no state vectors that need to be propagated with each Figure 6: Illustration of the Replace Manager oper-
operation. OT approaches for handling tree-like data ation type.
 The Replace Manager inherits its functionality from the Figure 8). An XML DOM Element2 has XML attributes
List Manager. Using this data representation, the first in- and an ordered list of children (XML elements or XML text).
sertion (which must not be a Delimiter) of a Replace Man- Therefore, we compose an XML-Type in YATA as a Map
ager denotes the actual content. In consequence, in order to Manager (which handles the XML attributes) and a List
replace this content once a user performs a new insertion, Manager (which handles the children). However, since the
the new content will be added as the first insertion of the List Manager and the Map Manager support to insert any
Replace Manager. In Figure 6 the red line references the value, we have to put some restrictions to the structure of
current content of the Replace Manager. Since YATA en- the XML-Type:
sures that all sites will have the same content in the end,
• The Map Manager, which handles the XML attributes,
all sites eventually reference the same insertion as the con-
must only map from a non-empty string to a non-
tent of the Replace Manager. Moreover, in order to free up
empty string
memory all other insertions can be implicitly deleted.
• The List Manager, which handles the children, must
4.3 Map Manager Operation only contain other XML types, or strings which repre-
A map is also known as a dictionary, or an associative sent XML text elements
array. It is an abstract data type that maps keys to values.
Figure 7 depicts YATA’s representation of a Map Man- 5. YJS: THE P2P SHARED EDITING FRAME-
ager operation. In order to support concurrent actions on
a shared map, we assign each key to a Replace Manager.
WORK
Therefore, the values addressed by keys will converge upon As already introduced, Yjs [19] is the open-source imple-
concurrent changes performed by multiple users i.e., users mentation of the YATA approach. In contrast to similar
collaboratively edit the content addressed by a specific key. OT, CRDT and shared editing implementations that sup-
We can use any map data structure to map keys to Replace port only a very limited number of document structures or
Managers. The values can contain primitive data types or represent them differently, the Yjs framework encourages
YATA own types. This construct is suitable for easily en- developers to build custom data types. A custom type can
abling collaboration on name/value pairs (e.g., objects, dic- use existing implemented types (as previously explained) in
tionaries, etc.). The current value of a key is replaced and order to give meaning to the actions on the data and to fire
retrieved by accessing the respective Replace Manager. custom events. At the time of writing this paper, Yjs has
implemented support for list, associative arrays, XML,text,
and rich text types. Yjs works on modern Web browsers, in-
Map Manager cluding mobile (on Android devices) and offers a quick and
id = x
easy way to embed collaboration in Web applications.
addressed by key1 addressed by key3
In order to maintain modularity and to be able to employ
addressed by key2 Yjs in various Web engineering settings, the communica-
Replace Replace Replace tion protocols and the shared data type formats support are
Manager Manager Manager implemented as dedicated interchangeable modules. This
greatly simplifies the process of integrating the framework
Figure 7: Illustration of the Map Manager operation into an existing project, since such projects typically use di-
type. verse communication protocols (e.g., WebRTC, Web Sock-
ets, XMPP), and collaborate on various data types and data
formats (e.g., XML, JSON, graphs). The support for the dif-
4.4 Representation of Specific Data Formats ferent communication protocols is implemented in connec-
tor modules. The collection of connector modules and type
Using YATA, by combining the simple types explained
modules are available as open-source JavaScript libraries on
above, data formats such as JSON or XML can be realized
GitHub3 . Currently, connectors are implemented for We-
as shared data types.
bRTC, Web Sockets and XMPP.
The JSON data format is built on collections of name/-
value pairs and ordered lists of values. Hence, with YATA
JSON can be easily created by using a Map Manager, in 6. EVALUATION
combination with other data types which can be used for
the attributes, such as further Map Manager operations or 6.1 Performance
List operations (for attributes implementing strings or ar- Apart from the correctness reasoning explained above, we
rays). have evaluated the approach and the Yjs library in terms
of responsiveness - how quickly an operation is integrated
XML-Type into each user’s local structure and scalability - what is the
impact of the number of users in this setting [19].
In order to evaluate the speed and correctness of YATA we
Map Manager Word performed multiple automatic tests simulating many users
attribute1
attribute2
attribute3 working exhaustively on a single shared document. The sim-
D D ulation introduced certain constraints: generation of ran-
dom operations, different arrival orders of operations at dif-
Figure 8: Illustration of XML as an operation type. ferent sites and network delay with operations which were
2
http://www.w3.org/TR/REC-xml/
3
YATA can also enable NRT collaboration on XML (cf. https://github.com/y-js
not ready to be applied because they were dependent on
other pending operations. As our implementation is meant
for client-side applications and runs on the Web, we could
not use existing benchmarking tools described in the litera-
ture [1]. Moreover, using collaboration logs from online text
editing systems such as Wikipedia would have lead to very
few conflicts on the shared document. Instead, we chose
an alternative approach with the goal to measure the fulfill-
ment of the NRT scenario in distributed settings. We first
used the testing environment with a test connector to mea-
sure the scaling capability with the number of operations by
measuring how many concurrent operations YATA can ap-
ply locally. Second, we measured the time performance for Figure 9: NRT performance for applying one remote
applying insert and delete operations between two Yjs in- operation with different content sizes
stances, including the network delay using the Web Sockets
connector. Similar to [1], we consider that the framework
performs in NRT if the response time for the insert operation This shows the delay between creating an operation on a
is in average under 50ms. site and seeing the effects of that change at the second site,
The testing environment can be configured with respect including the delay created from the message propagation
to number of users and number of actions that are created. across the communication channel (i.e., Web Sockets).
Furthermore, it is possible to configure the test environment The experiment (cf. Figure 9) was performed with a single
in such a way that the collaboration is restricted to a specific insert or delete operation using a text editor. Each operation
data type (e.g. text only or text and JSON with primitive was executed ten times in order to obtain a reliable estima-
data types). The users are collaborating concurrently with tion. We also increased the content of each operation (in
each other, whereby each simulated user can perform one characters), ranging from 1 to 103 characters. The results
of the following actions: wait for a time period, retrieve an for the insert operations are represented in gray and for the
operation from a random collaborator, go offline (all oper- delete operations in blue. As it can be observed, the average
ations that are currently sent to the users get lost. After time for all operations is smaller than 25 ms. We also used
going offline, the user is allowed to create more operations, the same environment to write a text of 1000 characters.
simulating late join), go online (user reconnects to all users, Here, we obtained an average execution time for an opera-
retrieves all missing operations, and sends all offline gener- tion of 12 ms, which is consistent with the results presented
ated operations). For text, a user can perform insert and in the figure for inserting and deleting one character.
delete actions. For JSON, the user can perform randomly Overall, the test results fulfill our expectations for the
the following actions: find a random child, create a new framework’s performance in NRT settings.
property, replace an existing property or delete a property.
When a configured amount of actions are executed, the 6.2 Applications
simulated users stop generating additional actions and wait
Overall, the Yjs library with its various connectors and
for all incoming operations to be executed. When the data
types was well received by the open-source developer com-
types of every simulated instance converge, we consider that
munity. The library’s Website and repository analytics show
the test framework succeeds.
that the Website gathered over one year more than 11600
We used our test framework with the creation and exe-
page views from over 4500 users and the library over 800
cution of 10000 actions on Text and JSON with a specified
downloads.
number of users, ranging from one to ten. The test ran on
Yjs was used to enable shared editing with the popular
one CPU only (Intel i7 - 3.40 GHz). All mentioned con-
Quill rich text editor, which is very similar to Google Docs.
straints were considered. We ran the test 15 times in order
The richtext component is already used by two companies
to get good average times. The time to create 10000 random
in production, for NRT shared text editing on the Web,
actions and apply them to all collaborators was measured
embedded in WebRTC video meeting tools.
and divided by the number of users times the number of
time As shown in Figure 10, Yjs is currently used for synchro-
created actions: operation per millisecond = 10000×|users|
nizing 3D objects movement across multiple users in the
The time for transforming operations did not thwart the Web browser4 .
performance noticeably. For a setting with 7 and 8 users, Here, the Map Manager is used in order to synchronize
the test framework registered 250 operations executed in one the position properties of a Javascript 3D object. This is
ms, whereas for 9 and 10 users the average time was approx. possible by observing changes in the x3dom 3D object rep-
230 operations per ms. This did not even change when we resentation and ensuring that the object’s coordinate values
restricted the test framework to work on text only, where are converging across all sites. The synchronization per-
even more conflicts should happen. formance and accuracy is currently being evaluated with
The time performance was measured using two Yjs in- students of the Faculty of Medicine from RWTH Aachen
stances using one Chrome browser on a laptop (Intel i7 - University, in an Exploratory Teaching Spaces project that
2.8 GHz) with a wireless Eduroam connection. Using Web aims to support formal and informal learning through NRT
Sockets connector, we measured the time difference (in ms) collaboration.
between applying an insert or delete operation on the first Furthermore, Yjs was used to create a tool for achieving
instance and applying the same operation on the second in-
stance. 4
http://eiche.informatik.rwth-aachen.de/3dnrt
 it guarantees a faster synchronization of the graph elements
and their respective properties with an increasing number
of users and operation content size in P2P settings. More-
over, Yjs SyncMeta reduces the network traffic through the
smaller size of messages, while keeping the reliability and
hence the convergence of the shared models across collabo-
rators.

7. CONCLUSION AND FUTURE WORK

In this work, we have described YATA, a new scalable
P2P approach for maintaining consistency of shared arbi-
trary data types, designed for NRT settings on the Web. We
proved that it ensures convergence and that it has several
advantages compared to other existing algorithms for shared
editing. The contributions of YATA rely on its flexibility for
various shared data types, as well as in its performance re-
garding the necessary number of exchanged updates between
collaboration sites, time to convergence and its support for
offline editing (enabled by YATA’s late join mechanism). Its’
Figure 10: Illustration of the 3D objects synchro- open-source implementation, Yjs, supports multiple NRT
nization with Yjs. communication protocols and can be easily used into exist-
ing and new applications for facilitating NRT collaboration
and shared editing.
In the future, we plan to change the available garbage
liquid Web applications [8], by providing a seamless user
collection mechanism in order to support operation removal
experience in using different Polymer Web components dis-
while working offline. Moreover, we want to improve the Yjs
tributed across various devices. The evaluation of a Yjs-
framework implementation with new supported data types
based collaborative drawing tool on Web videos [14] (per-
and persistence mechanisms for increasing the performance.
formed using the WebRTC connector) showed that during
Concerning persistence we are exploring efficient methods
concurrent drawings the framework proved to be reliable
for the storage of shared data in the P2P network that can
while keeping the NRT behavior, for all participating peers.
be included into the framework.
Several other examples for manipulating text, HTML5 ele-
As the main motivation for developing YATA and Yjs was
ments, JSON objects and additional usages in various projects
to enable easy NRT collaboration for online communities,
are provided on the Yjs Website.
we plan to use Yjs for the collaborative engineering of Web
Moreover, Yjs is currently being integrated into SyncMeta
applications and synchronizing the application content and
[5] (cf. Figure 11), a framework for enabling NRT collabo-
state across multiple devices [15].
rative (meta) modeling on the Web.

8. ACKNOWLEDGMENTS
This research was funded in part by the European Com-
mission in the projects “Layers” (FP7-318209) and “Metis”
(531262-LLP-2012-ES-KA3-KA3MP).

9. REFERENCES
[1] M. Ahmed-Nacer, C.-L. Ignat, G. Oster, H.-G. Roh,
and P. Urso. Evaluating CRDTs for Real-time
Document Editing. In Proceedings of the 11th ACM
symposium on Document engineering, pages 103–112.
ACM New York, 2011.
[2] L. Andre, S. Martin, G. Oster, and C.-L. Ignat.
Figure 11: Illustration of graph editing with Yjs. Supporting Adaptable Granularity of Changes for
Massive-scale Collaborative Editing. In
SyncMeta is using an OT solution for enabling shared edit- Collaboratecom 2013. IEEE, 2013.
ing on text and ensuring that the created nodes and edges [3] S. Androutsellis-Theotokis and D. Spinellis. A Survey
are converging during the modeling process at all sites. How- of Peer-to-peer Content Distribution Technologies.
ever, this solution uses timestamps for ensuring the consis- ACM Computing Surveys, 36(4):335–371, 2004.
tency in a P2P manner, which does not scale well with an [4] A. H. Davis, C. Sun, and J. Lu. Generalizing
increasing number of users. However, by synchronizing the Operational Transformation to the Standard General
underlying JSON model representation using YATA, Yjs is Markup Language. In CSCW ’02, pages 58–67. ACM,
a perfect candidate for achieving scalable optimistic NRT 2002.
collaborative modeling. The Yjs implementation benefits [5] M. Derntl, P. Nicolaescu, S. Erdtmann, R. Klamma,
from the advantages of YATA over OT algorithms. Thus, and M. Jarke. Near Real-Time Collaborative
 Conceptual Modeling on the Web. In ER’15, volume Editing on Arbitrary Data Types. In ICWE’15,
9381, pages 344–357. Springer International volume 9114, pages 675–678. Springer, 2015.
Publishing, 2015. [20] G. Oster, P. Urso, P. Molli, and A. Imine. Data
[6] C. A. Ellis and S. J. Gibbs. Concurrency Control in Consistency for P2P Collaborative Editing. In CSCW
Groupware Systems. In ACM SIGMOD ’89, ’06, pages 259–268. ACM Press.
volume 18, pages 399–407. ACM, 1989. [21] N. Preguiça, J. M. Marques, M. Shapiro, and
[7] N. Fraser. Differential synchronization. In Proceedings M. Letia. A Commutative Replicated Data Type for
of the 2009 ACM Symposium on Document Cooperative Editing. In 29th IEEE International
Engineering, pages 13–20. ACM, 2009. Conference on Distributed Computing Systems, 2009,
[8] A. Gallidabino and C. Pautasso. The Liquid.js pages 395–403. IEEE, 2009.
Framework for Migrating and Cloning Stateful Web [22] M. Ressel, D. Nitsche-Ruhland, and R. Gunzenhäuser.
Components across Multiple Devices. In WWW’16 An Integrating, Transformation-oriented Approach to
Companion, pages 183–186, 2016. Concurrency Control and Undo in Group Editors. In
[9] A. R. S. Gerlicher. A Framework for Real-time CSCW ’96, pages 288–297. ACM, 1996.
Collaborative Engineering in the Automotive [23] H.-G. Roh, M. Jeon, J.-S. Kim, and J. Lee. Replicated
Industries. In CDVE’06, pages 164–173. Abstract Data Types: Building Blocks for
Springer-Verlag, 2006. Collaborative Applications. Journal of Parallel and
[10] J. Grudin. Computer-Supported Cooperative Work: Distributed Computing, 71(3):354–368, 2011.
History and Focus. Computer, 27(5):19–26, 1994. [24] M. Shapiro, N. Preguiça, C. Baquero, and
[11] C. Ignat and M. C. Norrie. Tree-based Model M. Zawirski. A comprehensive study of Convergent
Algorithm for Maintaining Consistency in Real-Time and Commutative Replicated Data Types, 2011.
Collaborative Editing Systems. In CSCW ’02. ACM, [25] C. Sun. Undo As Concurrent Inverse in Group
2002. Editors. ACM Transactions on Computer-Human
[12] C.-L. Ignat and M. C. Norrie. Multi-level Editing of Interaction, 9(4):309–361, 2002.
Hierarchical Documents. Computer Supported [26] C. Sun and C. Ellis. Operational Transformation in
Cooperative Work, 17(5-6):423–468, 2008. Real-time Group Editors: Issues, Algorithms, and
[13] I. Koren, A. Guth, and R. Klamma. Shared Editing on Achievements. In CSCW ’98, pages 59–68.
the Web: A Classification of Developer Support [27] C. Sun, X. Jia, Y. Zhang, Y. Yang, and D. Chen.
Libraries. Collaboratecom 2013, pages 468–477. IEEE, Achieving Convergence, Causality Preservation, and
2013. Intention Preservation in Real-time Cooperative
[14] I. Koren, P. Nicolaescu, and R. Klamma. Editing Systems. ACM Transactions on
Collaborative Drawing Annotations on Web Videos. In Computer-Human Interaction, 5(1):63–108, 1998.
ICWE’15, volume 9114. Springer, 2015. [28] C. Sun, Y. Xu, and A. Agustina. Exhaustive Search of
[15] D. Kovachev, D. Renzel, P. Nicolaescu, I. Koren, and Puzzles in Operational Transformation. In CSCW ’14,
R. Klamma. DireWolf: A Framework for pages 519–529. ACM, 2014.
Widget-based Distributed User Interfaces. Journal of [29] D. Sun and Chengzheng Sun. Context-Based
Web Engineering, 13(3&4):203–222, 2014. Operational Transformation in Distributed
[16] R. Li, Du Li, and C. Sun. A Time Interval Based Collaborative Editing Systems. IEEE Transactions on
Consistency Control Algorithm for Interactive Parallel and Distributed Systems, 20(10):1454–1470,
Groupware Applications. In ICPADS ’04, pages 2009.
429–436. IEEE Computer Society, 2004. [30] D. Sun and C. Sun. Operation Context and
[17] Y. Liu, Y. Xu, S. J. Zhang, and C. Sun. Formal Context-based Operational Transformation. In CSCW
Verification of Operational Transformation. In FM ’06, pages 279–288. ACM Press, 2006.
2014: Formal Methods, volume 8442, pages 432–448. [31] S. Weiss, P. Urso, and P. Molli. Logoot-Undo:
Springer International Publishing, 2014. Distributed Collaborative Editing System on P2P
[18] D. A. Nichols, P. Curtis, M. Dixon, and J. Lamping. Networks. IEEE Transactions on Parallel and
High-latency, Low-bandwidth Windowing in the Distributed Systems, 21(8):1162–1174, 2010.
Jupiter Collaboration System. In UIST ’95, pages [32] Y. Xu, C. Sun, and M. Li. Achieving Convergence in
111–120. ACM, 1995. Operational Transformation: Conditions, Mechanisms
[19] P. Nicolaescu, K. Jahns, M. Derntl, and R. Klamma. and Systems. In CSCW ’14, pages 505–518. ACM,
Yjs: A Framework for Near Real-Time P2P Shared 2014.

View publication stats