Re: [aerogear-dev] Sync Day 2: All our cars are frozen in ice

On 01/30/2014 03:39 AM, Matthias Wessendorf wrote: > Oh, > > did you get a chance to read the mail/gist from Fabrice? > > * http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Conflicts-amp-Reco... > * https://gist.github.com/fabricematrat/8666682 > I've looked at it a couple of times but havn't written any code based on it so I'll hold off on any judgement.

> -M > > > On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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