[aerogear-dev] sync

[Summers Pittman]

On 01/05/2014 11:42 PM, Douglas Campos wrote:
> On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote:
>> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote:
>>> 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.
>> Because wrapping CouchDB and friends to AeroGear with no other reason
>> than to create a org.jboss.sync name space is dumb.
> can't +9001 enough
>
>> 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.
> drafted here: https://gist.github.com/qmx/8278287
>
> # 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.
>
> ### 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.

A good transport will include the change to sync (this can be a diff or 
a whole object), the revision on the client, and a checksum so the 
server can be sure that the object was updated correctly.

>
> ## 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?
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140106/ff8e67e3/attachment-0001.html