[aerogear-dev] sync

[Lucas Holmquist]

On Jan 5, 2014, at 11:42 PM, Douglas Campos <qmx at qmx.me> 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
> 
where does the more than 2 users editing something fall.

so if say 4 people are editing something offline and then come back online,  who wins that one.


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