On 02/10/2014 10:47 AM, Corinne Krych wrote:
On 10 Feb 2014, at 15:46, Summers Pittman <supittma(a)redhat.com>
> On 02/10/2014 06:38 AM, Corinne Krych wrote:
>> Hello Guys,
>> Following discussion on ML thread , and JIRA discussion  (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) 
>> 2. SyncPipe(ios naming) 
>> 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
> 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)
@summers : Where is your SyncPipe/DataSync/ConflictMgr/VersionControlMgr in
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
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.
> 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.
>>  https://issues.jboss.org/browse/AEROGEAR-1408
>>  https://gist.github.com/lholmquist/81de9737b5c91367aa3c
>>  https://gist.github.com/corinnekrych/8914290
>> aerogear-dev mailing list
> aerogear-dev mailing list
aerogear-dev mailing list