[aerogear-dev] Sync Day 3 Sync takes Manhattan

[Lucas Holmquist]

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

> 
> 
> 
> On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma at 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.
> 
> +1
>  
> 
> 
> 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
> 
> 
> +1

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
> +1
>  
> 
> M4 - Server user management, Network Management, Server side session
> management
>    * 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"
> abilities.
>    * 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
> 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/ff98a7fb/attachment.html