On 10 Feb 2014, at 15:46, Summers Pittman <supittma(a)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/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