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

Thu Jan 30 03:48:03 EST 2014

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

>
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/601e8e9c/attachment-0001.html 