On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman <supittma@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? 
 


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) ?
 

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
 

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)
 
  * 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

 

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
 

M7 - Party
  * We have a sync party.

Jägermeister and fine brews from Russian River -> yay!
 
_______________________________________________
aerogear-dev mailing list
aerogear-dev@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