[aerogear-dev] Data Sync Thoughts

[Matthias Wessendorf]

On Tue, Jan 28, 2014 at 5:41 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:

>
> On Jan 28, 2014, at 11:01 AM, Summers Pittman <supittma at redhat.com> wrote:
>
> > On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
> >> On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma at redhat.com>
> wrote:
> >>
> >>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
> >>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma at redhat.com>
> wrote:
> >>>>
> >>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote:
> >>>>>> yup, this is another Data Sync thread,
> >>>>>>
> >>>>>>> From a client side perspective, i have concerns that there is
> still not a clear direction yet.
> >>>>>> I know there are multiple ideas floating around on what our model
> should be,  i'm all for choice, but what about deciding on 1 model to get
> started with.  Then later once we have this nailed down,  we can have other
> "adapters" with different models perhaps
> >>>>> All the data model is is an envelope of sync metadata around an
> object
> >>>>> right?
> >>>> right
> >>>>
> >>>>> We also need to think about the API and server/client protocol as
> well.
> >>>>>
> >>>>> I think that for sync 1.0 we could focus on the following behavior
> (it
> >>>>> worked for my demos at least)
> >>>>>
> >>>>> 1.  We have a Sync factory similar to Pipeline, Authenticator,
> >>>>> Registrar, and KeyService.
> >>>>> 2.  The Sync factory consumes/manages Synchronizer instances.
> >>>>> 3.  AG Synchronizer listens for sync messages using UnifiedPush
> endpoints.
> >>>> i thought for a 1.0 we weren't thinking about "realtime"
> >>> When I hear realtime I think sub 100 ms updates to all clients. (think
> >>> gaming)
> >>>
> >>> What I thought we were going for was something closer to email.  The
> >>> data gets changed and at some point in the future the client knows.
> More
> >>> specifically, the thing the ONE thing that makes sync special is it is
> a
> >>> push instead of poll implementation.
> >> this makes sense,  but i guess it would be push when available.
> thinking web and crappy web socket support( dang you carriers )
> > Right.  I'm not saying lets do something complicated.  I'm saying lets
> > use GCM, iOS CM, and simple push to send notifications to tell the
> > client something.  In simplePush case it is "this data changed, get the
> > new stuff and update yourself".  In Android and iOS case it may be that
> > or it may be "here is new data".
> >
> > In general, I am fine for getting a message saying something like
> > Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
> > data if necessary, update my local data, and send any updates.  That
> > SHOULD (I think) be doable with simplepush as well right?
>
>
> not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for
> sync.
>
> then we are relying on these 3rd party services,
>


+1





>
> >
> >>
> >>>>> 4.  AG Synchronizer sends sync messages using Pipes
> >>>>> 5.  AG Synchronizer holds local data in a store
> >>>>>
> >>>>> 6.  When AGSynchronizer gets a message it is responsible for updating
> >>>>> the Store and then notifying code listing for updates OR for
> notifying
> >>>>> the code that an error has occurred and needs to be addressed.
> >>>>>
> >>>>> 7.  When the developer updates data in the store, the synchronizer
> >>>>> should package that data and send it to the server.  The
> synchronizer is
> >>>>> responsible for error handling, retrying, back-off, etc.
> >>>>>
> >>>>> 8.  We should include multiple synchronizer implementations to deal
> with
> >>>>> multiple very simple use cases which involve legacy systems. (For
> >>>>> instance polling to load static data on a schedule.)
> >>>>>
> >>>>> Thoughts? Tomatoes?
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> >>
> >> _______________________________________________
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/fd430f0f/attachment.html