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

Summers Pittman supittma at redhat.com
Thu Jan 30 10:04:35 EST 2014


On 01/30/2014 03:32 AM, Matthias Wessendorf wrote:
>
> On Wed, Jan 29, 2014 at 5:57 PM, Jay Balunas <jbalunas at redhat.com 
> <mailto:jbalunas at redhat.com>> wrote:
>
>     Finally got a chance to read through the whole sync thread :-)
>
>     I'm a big fan keeping it simple, especially for initial releases.
>      So limiting scope of our initial offering will be important imo.
>
>     I really like the idea of defining the data model, protocol,
>     client contract, etc... separate from a specific implementation.
>      As several have said, those are impl. details that we can change
>     as needed.  For example Push - I like the idea of using it for
>     notification of updates (optional, with fallback, & not required),
>     but it should not be a 1.0 priority imo.  It should also be
>     something that requires no (or minimal) updates from the app
>     developer when we implement it.  At the end of the day it is just
>     another way to let the app know something has changed :-)
>
>     As for versioning, I'm concerned over having M1, M2, etc....  What
>     do you think of sticking with semver 0.1, 0.2, etc...?
>
>     On Jan 29, 2014, at 10:41 AM, 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.
>
>     +1 and thanks
>
>     >
>     > 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.
>
>     I would recommend at this point keep it free from implementation
>     and/or have that implementation be as simple as possible.  This
>     way we can get through to the next stage quickly, without debating
>     the specific impl.
>
>
> what do you mean ? Just specs and papers ? Not sure I follow on 
> keeping it "free from implementation"
Bump.  I'm also curious what you meant.
>
>
>     >
>     >
>     > 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
>
>     I agree we need to plan for the future with user management and
>     security  integration, but I might move that part to a later point
>     release to keep this as simple as possible.
>
>
> user mgmt - keycloak :-)
> Ok, we should not really go there, yet :-))
>
>
>     Other than my comments above this looks like a good overall plan :-)
>
>     Once we nail this down we'll want to talk about possible dates,
>     and how we split time with other priorities as well (developer
>     experience, getting started, examples, site, etc....)
>
>     >
>     > 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
>
>
>     _______________________________________________
>     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/54e6ed45/attachment.html 


More information about the aerogear-dev mailing list