[aerogear-dev] DataSync or SyncPipe API proposal

[Summers Pittman]

On 02/10/2014 10:47 AM, Corinne Krych wrote:
> 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 ?
That is the Synchronizer interface.

As I said, this was done BEFORE we had any of these concepts (even at 
this stage) and reflects a FUNDAMENTALLY DIFFERENT idea of how sync 
should work.

Also I tossed up up months ago and people really didn't comment on it 
(other than to say this is where we would like to end up).
>
>
>>> 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
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev