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

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... ?

>> 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