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

Corinne Krych corinnekrych at gmail.com
Thu Jan 30 03:54:54 EST 2014 

On 30 Jan 2014, at 09:48, Matthias Wessendorf <matzew at apache.org> wrote:

> 
> 
> 
> On Thu, Jan 30, 2014 at 9:40 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
> 
> On 30 Jan 2014, at 09:38, Matthias Wessendorf <matzew at apache.org> wrote:
> 
> >
> >
> >
> > On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych <corinnekrych at gmail.com> wrote:
> > Hi All,
> >
> > #agreed Good to have a plan with associated JIRA to help keep the focus on sync.
> >
> > +1
> >
> > For v0.1, I’d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I’ve started with Buddies’Hobbies app from Luke[1], I’m planning to add to ios-cookbook for our initial sync.
> > Ok to add a demo JIRA for that? or any better idea for demo app?
> >
> > You mean a demo app in addition, right?
> 
> Yes, a demo app to test our use cases for v0.1
> keep it simple like Luke’s demo
> 
> yeah :-) I agree 
>  
> 
> >
> >
> > To me v0.1 and v0.2 could be grouped together.
> > v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener)
> >
> > hrm, not sure tbh
> 
> Not sure for what grouped 0.1/0.2 or v0.2 without Auth Authz?
> 
> not sure on the grouping

ok no grouping then
0.1 - set up demo, sync pipe (find a name), detect conflics
0.2 - pluggable conflict resolution
0.3 - Auth/authz

ok like this?

>  
> 
> >
> > v0.3 could be focus on auth/authz
> > and then as you stated
> >
> > Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert).
> > In spec doc we should refine vocabulary, let’s have a JIRa for that too…
> >
> > While you’re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]?
> >
> > ++
> > Corinne
> > [1] https://github.com/lholmquist/ag-js-ds-poc
> > [2] https://gist.github.com/fabricematrat/8666682
> > [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps
> > On 29 Jan 2014, at 18:11, Summers Pittman <supittma at redhat.com> wrote:
> > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote:
> > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman <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.
> > >>>
> > >>>
> > >>> 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
> > >>>
> > >>> M3 - Push based Sync Listener, Network Management, Serverside session
> > >>> management
> > >> when we say push here, are we talking about the 3rd party services such as GCM and APN's,  if so, not sure that is a great idea
> > > A one way notification service which only guarantees eventual delivery.
> > > GCM and APN is an example of this type of service but I explicitly left
> > > it out and think we should target consuming messages from the unified
> > > push server.  This may mean that we implement SimplePush on iOS and
> > > Android so we are "pure" and bundle the simple push server into the sync
> > > server contract.
> > >>
> > >>>  * 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
> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> 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

More information about the aerogear-dev mailing list