Re: [aerogear-dev] DataSync or SyncPipe API proposal

On 02/10/2014 10:47 AM, Corinne Krych wrote: > On 10 Feb 2014, at 15:46, Summers Pittman <supittma(a)redhat.com&gt; 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/j... ? 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/j... >> and >> https://github.com/aerogear/aerogear-android/blob/sync_strawman/src/org/j... >> >> 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-no... >>> [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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev