[aerogear-dev] DataSync or SyncPipe API proposal

Corinne Krych corinnekrych at gmail.com
Mon Feb 10 10:47:21 EST 2014


On 10 Feb 2014, at 15:46, Summers Pittman <supittma at redhat.com> wrote:

> On 02/10/2014 06:38 AM, Corinne Krych wrote:
>> Hello Guys,
>> 
>> Following discussion on ML thread [1], and JIRA discussion [2] (sorry guys I catched up the discussion late, I wasn’t watching the JIRa ticket so i didn’t get notifications) here is the 2 gists we have:
>> 1. DataSync (JS naming) [3]
>> 2. SyncPipe(ios naming) [4]
>> 
>> I guess we should call them the same and agree on a name. I like to use ‘pipe’ in the naming just to recall it’s async and going through network.
> Not necessarily.  Managing revisions and checking two documents for 
> conflicts Shouldn't require network usage.
>> I found DataSync a too generic term which may lead to confusion. This is not the same object that will save data offline and trigger sync.
> Right.  This is basically an inspection into the state of sync offering 
> two items of information
> 1) Is there a new document on the server
> 2) Does replacing the synced document with a revised document generate a 
> conflict
> 
> and it offers a convenience function
> a) Update this documents revision.  If there is a conflict tell me.
> 
> Managing the client<-> Server connection is outside of the object (and 
> can be delegated to a Pipe)

oki 
@summers : Where is your SyncPipe/DataSync/ConflictMgr/VersionControlMgr in 
https://github.com/aerogear/aerogear-android/tree/sync_strawman/src/org/jboss/aerogear/android/sync ?


> 
>> 
>> Main differences are: in iOS one I defined a readAll method. Also for save/update I define a third callbacks ‘conflict’ which take 3 arguments .
>> 
>> @summers do you have a gist for java API?
> I took a completely different approach a long time ago to this.  My idea 
> was there is an object which does the thing I just described and you 
> register listeners on it for it to callback to.
> 
> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/Synchronizer.java
> and
> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/jboss/aerogear/android/sync/SynchronizeEventListener.java
> 
> Obviously this is slightly out of date, but I havn't really been 
> satisfied with the proposals so far.  They feel too imperative and 
> developer driven.  I'm not really sure how they will fit when we expand 
> them into something which can be automated by the underlying system.
>> thoughts?
>> 
>> ++
>> Corinne
>> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-sync-To-pipe-or-not-to-pipe-td6135.html
>> [2] https://issues.jboss.org/browse/AEROGEAR-1408
>> [3] https://gist.github.com/lholmquist/81de9737b5c91367aa3c
>> [4] https://gist.github.com/corinnekrych/8914290
>> _______________________________________________
>> 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




More information about the aerogear-dev mailing list