[aerogear-dev] sync

[Summers Pittman]

On 01/06/2014 09:29 AM, Lucas Holmquist wrote:
> 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.
I think that would be level 2.  Either the developer would write a 
business rule or choose a provided conflict resolution strategy object.

I think AbstractConflictResolutionStrategyFactory is too awesome of a 
class name to miss out on now :)
>
>
>> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev