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

[Summers Pittman]

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-Reconciliation-td6026.html
> * 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 at redhat.com 
> <mailto: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 <mailto:aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/fb9886e1/attachment-0001.html