Editor Comments
Comments to the Author
Reviewer 2 and 3 still have minor concerns about the importance of
server and section 3. Authors shall prepare a minor revision to address
them.
Reviewer 3
Recommendation
Accept With No Changes
Comments
With this revision the authors improved the manuscript and addressed the
issues raised in the previous version and provided detailed explanations
to the reviewers. I believe this version can now be accepted with no
further changes required.
Additional Questions
-
Please explain how this manuscript advances this field of research
and/or contributes something new to the literature.: The paper
presents a state based CRDT design and web based middleware in JS for
a recursive observed remove map with leafs being last-writer-wins
registers. The recursive construction resorts to pointers to a
key-value store and uses merkle-trees to efficiently detect
sub-portions of the structure that are unchanged and avoid
synchronization of those.
While the design uses standard CRDT techniques, such as sets of
tombstones instead of version vectors common to the whole tree, it
does a good job of motivating with real use cases and doing an
extensive comparison with competing designs of web based middlewares.
-
Is the manuscript technically sound? Please explain your answer under
Public Comments below.: Yes
-
Which category describes this manuscript?: Practice / Application /
Case Study / Experience Report
-
How relevant is this manuscript to the readers of this periodical?
Please explain your rating under Public Comments below.: Relevant
-
Are the title, abstract, and keywords appropriate? Please explain
under Public Comments below.: Yes
-
Does the manuscript contain sufficient and appropriate references?
Please explain under Public Comments below.: References are sufficient
and appropriate
-
Does the introduction state the objectives of the manuscript in terms
that encourage the reader to read on? Please explain your answer under
Public Comments below.: Yes
-
How would you rate the organization of the manuscript? Is it focused?
Is the length appropriate for the topic? Please explain under Public
Comments below.: Satisfactory
-
Please rate the readability of the manuscript. Explain your rating
under Public Comments below.: Easy to read
-
Should the supplemental material be included? (Click on the
Supplementary Files icon to view files): Does not apply, no
supplementary files included
- If yes to 6, should it be accepted: As is
-
Would you recommend adding the code/data associated with this paper to
help address your concerns and/or strengthen the paper?: No
Please rate the manuscript. Please explain your choice.: Excellent
Reviewer 2
Recommendation
Author Should Prepare A Minor Revision
Comments
The authors have done a good job in addressing most of the concerns I
had on the first submission. In particular, the CRDT description in
Section 3 is much more precise now and significant errors have been
removed. I am now confident that the authors approach is indeed valid.
I still have minor concerns with Section 3, though. It is still somewhat
difficult to understand without reading Section 4 first, so it is not
possible to read the paper sequentially from beginning to end.
-
With a standard CRDT, a full update is sent over the network, and
MERGE simply merges that update. Here, we have a more complex
situation, MERGE takes an additional path argument (and it is not
fully clear what this parameter exactly means), and returns a list of
to-update items. In my opinion, at least a brief explanation of what
this return value means would be helpful. (A sends an update to B, and
the MERGE function at B produces a return value, but then further
interaction between A and B will be necessary, and at that point,
without reading Sect. 4, it is fully unclear what this actually
means.).
-
Also I had to read Section 4 to understand the p0,..pn part of the
MERGE parameters. Explaining something like "if a state update is sent
for drawing1.object36, MERGE is first called at the root node with
path "drawing1.object36", which then recursively calls MERGE at
drawing1 with p0..pn="object36", which in turn invokes MERGE at
drawing1.object36 with p0..pn="" " would have been a great help for
me.
-
The proof sketch is not fully convincing, and I guess the main problem
is that the presented Alg.2 is incomplete. At least it is non-trivial
to see that the claimed "monotonic join semilatice" indeed is
satisfied. Lets for example assume that an additional key
"fillpattern" is added to drawing1.object36. The MERGE function that
is called at that object does merge the R-set (line 43), but line 44
only removes element from the local O, the elements of the remote O
are NOT added directly to the local O set. Instead
"drawing1.object36.fillpattern" is added to the return value. Now its
necessary to look at Alg. 3 first to see we happens. On that basis,
eventually a MERGE with path "drawing1.object36.fillpattern" is
invoked at the root, which means that MERGE(fillpattern,..) is invoked
on drawing1.object36, and lines 62--64 indeed add something the local
O. However, in this case a LWWRegister should be added for
fillpattern, and the code shown in Alg.2 adds an ORMap.
Minor items:
-
For formal statements such that "if an element o in O exists such that
o satisfies some property", the authors use an "and"-sign (∧) for
"such that", which I consider non-standard. Any of the notations
"s.t.", ":", or "|" would be more appropriate (e.g., Alg. 1, lines 8,
13, 22, 32 and 35)
-
Alg. 3 uses "PUSH" for two different things, first the PUSH message as
defined at the beginning of Section 4.3, and second as a local method
to add something to a list of responses. That naming is somewhat
confusing, and using a different notation for the second operation
might help avoid this confusion (e.g., response.add or
response.append)
- Fig. 2 caption: s/key-calues/key-values/
-
p7 last par before 4.3. "If there would be .. they will" is
grammatically wrong
Additional Questions
-
Please explain how this manuscript advances this field of research
and/or contributes something new to the literature.: (see review of
first version)
-
Is the manuscript technically sound? Please explain your answer under
Public Comments below.: Appears to be - but didn't check completely
- Which category describes this manuscript?: Research/Technology
-
How relevant is this manuscript to the readers of this periodical?
Please explain your rating under Public Comments below.: Relevant
-
Are the title, abstract, and keywords appropriate? Please explain
under Public Comments below.: Yes
-
Does the manuscript contain sufficient and appropriate references?
Please explain under Public Comments below.: References are sufficient
and appropriate
-
Does the introduction state the objectives of the manuscript in terms
that encourage the reader to read on? Please explain your answer under
Public Comments below.: Yes
-
How would you rate the organization of the manuscript? Is it focused?
Is the length appropriate for the topic? Please explain under Public
Comments below.: Satisfactory
-
Please rate the readability of the manuscript. Explain your rating
under Public Comments below.: Readable - but requires some effort to
understand
-
Should the supplemental material be included? (Click on the
Supplementary Files icon to view files): Does not apply, no
supplementary files included
-
If yes to 6, should it be accepted: After revisions. Please include
explanation under Public Comments below.
-
Would you recommend adding the code/data associated with this paper to
help address your concerns and/or strengthen the paper?: Yes
Please rate the manuscript. Please explain your choice.: Good
Reviewer 1
Recommendation
Author Should Prepare A Minor Revision
Comments
I would like to thanks the authors for their effort in improving the
paper. Most of my concerns and comments have been satisfactorily
addressed. I have two concerns left:
-
I do not agree with the authors that resource usage at the server is
not as important as the client. In fact, for a server that needs to
maintain thousands of applications, for instance, Google Docs,
resource usage is very important. Given that OWebSync is costlier than
some alternatives, which is understandable, such costs should be
mentioned explicitly in the text. I understand the space constraints,
but still, I believe the paper would benefit from a short paragraph
(such as the one that the authors provided in the letter), discussing
the cost of each approach.
-
The discussion on the different trade-offs a developer faces when
using OWebSync, in response to one of my comments, is an interesting
one, and the paper would benefit from it. However, in the interest of
space, this could be dropped in favor of my previous comment
Additional Questions
-
Please explain how this manuscript advances this field of research
and/or contributes something new to the literature.: This paper
presents a technique to improve the synchronization time of
collaborative web-based applications subject to frequent offline
periods.
-
Is the manuscript technically sound? Please explain your answer under
Public Comments below.: Yes
- Which category describes this manuscript?: Research/Technology
-
How relevant is this manuscript to the readers of this periodical?
Please explain your rating under Public Comments below.: Relevant
-
Are the title, abstract, and keywords appropriate? Please explain
under Public Comments below.: Yes
-
Does the manuscript contain sufficient and appropriate references?
Please explain under Public Comments below.: References are sufficient
and appropriate
-
Does the introduction state the objectives of the manuscript in terms
that encourage the reader to read on? Please explain your answer under
Public Comments below.: Yes
-
How would you rate the organization of the manuscript? Is it focused?
Is the length appropriate for the topic? Please explain under Public
Comments below.: Satisfactory
-
Please rate the readability of the manuscript. Explain your rating
under Public Comments below.: Easy to read
-
Should the supplemental material be included? (Click on the
Supplementary Files icon to view files): Does not apply, no
supplementary files included
-
If yes to 6, should it be accepted: After revisions. Please include
explanation under Public Comments below.
-
Would you recommend adding the code/data associated with this paper to
help address your concerns and/or strengthen the paper?: Yes
Please rate the manuscript. Please explain your choice.: Good