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

[Lucas Holmquist]

On Jan 29, 2014, at 10:41 AM, Summers Pittman <supittma at redhat.com> 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
when we say push here, are we talking about the 3rd party services such as GCM and APN's,  if so, not sure that is a great idea

>  * 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev