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

[Summers Pittman]

On 01/30/2014 03:22 AM, Matthias Wessendorf wrote:
>
>
>
> 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.
>
>
> what about looking at local changes ? Is that implied here?
Right.  Basically the first thing we should have is some way of 
detecting if the local data and server data are out of sync with one 
another.

I'll follow up later with a bit more indepth discussion on how we do 
that.  (Diff-merge-patch and revision control are the two being worked 
on in the sync server right now).

>
>
>     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
>
>
> Not sure, but: could/should a  user get the chance to kinda control 
> that 'change' (e.g. veto) ?
It depends on the architecture of the application.  In a peer to peer 
system like say email then maybe.  In a client/server system like 
mediawiki then that is probably a no.

Something to think about on the JIRA.

>
>     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.
>
>
> I still think this is optional :-)
>
> I think generally it's nice to have feature that the "sync-server" can 
> send 'update requests'
> to the unifiedpush server; However IMO the clients should still mark 
> this as optional (again
> a user (on iOS/FFOS) can decide she is not interested in push 
> notification; Than all the offerings
> from M3 would just not work
Yes a user on iOS and FFx can turn off parts of M3.  However M3 builds 
the foundation for M4.

Additionally network management and intermittent connectivity ARE 
problems for all platforms and they are also addressed in this bundle.

>
>     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.
>
>
> Should be the default when an app is active and open (putting platform 
> limits aside)
Managing that is what M6 is about.
>
>     * Previous Sync listeners may have to be upgraded to include "upload"
>     abilities.
>       * The server will need to support this as well.
>
>
> This step might allow us (*later*) to plug in some sort of OT 
> (Operational Transform) implementation
Well before this the way uploading was done was out of band with the 
sync channel.  Before M4 this was one way sync (server -> client) with 
the application pushing changes to the server.  Now the idea is that 
library will have support for pushing changes automatically.
>
>
>     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
>
>
> +1
>
>
>     M6 - Sync connection Upgrading
>       * The client and server will negotiate when it is appropriate to
>     switch between polling, push, and realtime sync strategies.
>
>
> yeah, sounds good
Maybe this should be moved to before automagic conflict resolution (M5)
>
>
>     M7 - Party
>       * We have a sync party.
>
>
> Jägermeister and fine brews from Russian River -> yay!
:-D
>
>     _______________________________________________
>     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/6859e01c/attachment-0001.html