[aerogear-dev] Sync Day 2: All our cars are frozen in ice
Bruno Oliveira
bruno at abstractj.org
Wed Jan 29 11:05:33 EST 2014
+1
Agreed on all points, thanks Summers!
--
abstractj
On January 29, 2014 at 1:41:38 PM, 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
> * 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
>
More information about the aerogear-dev
mailing list