On Jan 30, 2014, at 11:03 AM, Matthias Wessendorf <matzew@apache.org> wrote:

On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma@redhat.com> wrote:
I rolled up the feedback to the email I sent yesterday.

One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan.  It is
probably closer to a 1.5 or 2.0 plan in terms of scope.

ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I understand that
 I tried to
order things and break out big "chunks" which will need to be done and
the approximate order they should be done in while also drawing a line
around what features we have.  This is why I have not placed ANY
versions YET.  By the end of today/tomorrow morning I hope that we will
be in a good place to do that.


Big changes from yesterday, User mgmt moved to M4.  M6 (Sync Listener
Upgrading)was merged into M3(Push Listeners) so that we can have
optional push sooner.

# 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,

   * 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


somewhat related  http://blog.lholmquist.org/img/ab_sync_conflict.jpg


M3 - Push based Sync Listener, Sync Listener Strategy Management
   * The client and server will negotiate when it is appropriate to
switch between polling, push, and realtime sync strategies.
   * We will build on our previous Listener work from M2 to include a
Push listener that the server can speak to.
   * We will support ways of automagically managing sync listeners based
on the availability of Push.

overall, yes - the nasty details can be discussed at a later point, hence

M4 - Server user management, Network Management, Server side session
   * 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.
  * The server should have a basic authentication and authorization plan
for controlling how data is synced

this assume we do have a server w/ pluggable adapters, no ? 
E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter

M5 - "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"
   * We will also include the ability to switch between Realtime sync
listeners, polling listeners, and push listeners
   * The server will need to support this as well.

Didn't M3 already include 'realtime' ? 

M6 - 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

M8 - Party
   * We have a sync party.

what about M7?  :)
aerogear-dev mailing list

Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
aerogear-dev mailing list