[aerogear-dev] Data Sync Thoughts

Tue Jan 28 12:19:56 EST 2014

On Tue, Jan 28, 2014 at 6:14 PM, Summers Pittman <supittma at redhat.com>wrote:

> On 01/28/2014 11:41 AM, Lucas Holmquist 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,
> That is a valid concern.
>
> I think making our entire sync product based on polling is a bad thing.
> (Battery, performance, etc etc etc).
> I think making sync based on TCP sockets/WebSockets/SockJS is a good
> thing, but it is past 1.0
>

regarding 1.0 - I am not even sure what that version should be done; but
for me (personal thought),
I (again, personally) have serious doubts that the first sync offerings
(March/April?) will be the ones labeled as '1.0.0';

> I think making our sync product demand proprietary technology is a bad
> thing, but I don't know of a service which is as easy as APNS or GCM for
> iOS and Android devs.
>
>
>
> >
> >>>>>> 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
>
> _______________________________________________
> 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/b3392d38/attachment.html 