<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/05/2014 11:42 PM, Douglas Campos
wrote:<br>
</div>
<blockquote cite="mid:20140106044233.GA70219@rohan.local"
type="cite">
<pre wrap="">On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/20/2013 06:34 AM, Erik Jan de Wit wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So we already agreed that CouchDB has some nice features, but why
wouldn’t we just use pouchdb for javascript and touchdb? I’ve just
tested the javascript and it syncs with the server perfectly, even
if there are some things missing we could add them because these
projects are open source.
</pre>
</blockquote>
<pre wrap="">Because wrapping CouchDB and friends to AeroGear with no other reason
than to create a org.jboss.sync name space is dumb.
</pre>
</blockquote>
<pre wrap="">
can't +9001 enough
</pre>
<blockquote type="cite">
<pre wrap="">Also the how of sync is still a bit far off. I'm still interested in the
"what" of sync. What use cases are we supporting, what features are we
supporting, what are our goals, what does a working finished sync impl
look like, etc.
</pre>
</blockquote>
<pre wrap="">
drafted here: <a class="moz-txt-link-freetext" href="https://gist.github.com/qmx/8278287">https://gist.github.com/qmx/8278287</a>
# aerogear-sync
While I was reviewing Summers' code and ideas, I realized that I really wanted
everything he did, but as a second step after we nail down the basics.
## basics?
Since we've been catering the enterprise market, this essentially means we need
to get the __boring__ stuff right first, then move over to the __shiny__ stuff,
like realtime data sync, update policies & friends.</pre>
</blockquote>
<blockquote cite="mid:20140106044233.GA70219@rohan.local"
type="cite">
<pre wrap="">
### data model
For starters, I think that the most important thing that needs to be agreed
upon is the data model and the atomic operations around it. As previous
discussed, I really like CouchDB's datamodel -- and hate erlang ;)
`{_id:<guid>, content:<arbitrary json>, rev:<last revision>}`
#### JS
Well, it's JSON, it _Just Works_&trade;
#### Java
I didn't want to pick on Java, but since its fame forces me to it. First stab
(a courtesy of our friend Dan Bevenius):
public interface Document {
public String id;
public String content;
public String rev;
}
We naturally want to kick this a notch, and use objects instead of plain strings:
public interface Document<T, ID> {
public ID id;
public T content;
public String rev;
}
In this case, we can use the convention requiring that `T` is any **object
serializable to JSON**. `ID` is a convenience shorthand since it's a
**GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate
key instead).
#### Objective-C
<volunteers needed> ;)
### API levels
As soon as we have a rough data-model defined, we can start dabbling around
different API levels to be served:
(parts **I think** are potentially deliverable for a 1.0)
- level 0: explodes when there's a conflict
- level 1: semi-automatic conflict resolution via something like google's diff-match-patch
- level 2: business rules determine who wins a conflicting update (supervisor
wins over normal user)
(parts **I think** are potentially deliverable for a 2.0)
- level 3: real-time updates via diff-match-patch
- level 4: real-time updates via OT/EC
All those proposed API operations should be serializable, meaning I can
potentially keep doing changes offline then just replying them to the server
when online.
### transport
Since we know about the future-looking ideas on v2.0, it would be really nice
for us to specify a very simple/dumb JSON-based protocol for those change
messages. Something that could accomodate both the full document updates and
the OT/EC incremental bits too. I have no ideas on this, tbh.
## boring usecases
### scenario 1
Building inspector system - we have mobile apps that store relevant info and
are bound to be accessed on places where we won't have any kind of connection,
or very poor signal.
You can have several inspectors screening the same building simultaneously.
Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a
new hospital building. Technically each fire extinguisher has its own
identifier and can be an independent document. In this case we would have no
conflict happening.
Now they start finding expired fire extinguishers and start to add them to the
report. This report could potentially have two divergent lists of fire
extinguishers to be replenished/revalidated, as the building's compliance
status.
### scenario 2
Census system - we have mobile apps focused on offline data collection. We have
the previous year's info that needs to be updated on the server. The
interviewee needs to take a call, then asks the interviewer to come back later.
This results in two sets of changes for the same document, stacked together,
which should work flawlessly.
Any other ideas/comments?</pre>
</blockquote>
<br>
I'll add now :)<br>
<br>
## Transactions<br>
<br>
These are the most basic parts of sync I can think of that our
system should be able to do/manage. Our internal representation of
the client documents and collections should make implementing this
automatically and without user intervention as simple as possible<br>
<br>
<div class="ace-line" id="magicdomid1185"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq">* Detect
Change</span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"></span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
When a user changes her local data, the system should note
the change and generate a sync message to send to the server.
This can be done automatically or manually but SHOULD be done
automatically.</span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
<br>
* Send update</span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"></span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
When a sync message is ready to be sent, and the system
allows for it to be sent (network available, not in blackout
window from exponential backoff, etc) then sync message should
be sent. This SHOULD be done automatically. </span><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
<br>
* Receive Update<br>
</span><span class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"></span></div>
<div class="ace-line" id="magicdomid1321"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"> When a
client updates it data and successfully syncs to the remote
server, the remote server will notify all of the relevant
clients. The client must automatically and without user
intervention receive this update and either act on it or store
it for later processing.<br>
</span></div>
<div class="ace-line" id="magicdomid1322"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
* Apply Update</span></div>
<div class="ace-line" id="magicdomid1326"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"> Once a
client application has an update message from the server, it can
apply the message correctly to the data on it. This should be
done automatically as part of receiving the update, but it may
be done manually or may be delayed and automatically executed
later.<br>
</span></div>
<div class="ace-line" id="magicdomid1332"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"><br>
* Detect Conflict</span></div>
<div class="ace-line" id="magicdomid1340"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"> When
applying an update fails, the system must detect this. The
system will provide state to the application and/or the user to
handle the conflict. The user MUST NOT have to check for
conflicts on her own.<br>
<br>
</span></div>
<div class="ace-line" id="magicdomid1327"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq">* Resolve
Conflict</span></div>
<div class="ace-line" id="magicdomid1331"><span
class="author-a-sssjz74zz122zlbfz75z2z87zqz65zz82zq"> There
must be a mechanism for resolving a conflict. The CAN be done
automatically using default resolvers provided by AeroGear, by
using a resolver provided by the developer/user, or by the app
user selecting the correct merge. This will probably generate a
new sync message.<br>
<br>
</span></div>
<br>
<br>
<blockquote cite="mid:20140106044233.GA70219@rohan.local"
type="cite">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aerogear-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></pre>
</blockquote>
<br>
</body>
</html>