Re: [aerogear-dev] Data Sync Thoughts

On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > > On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >> >> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> >>> wrote: >>> >>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>> <supittma(a)redhat.com >>> <mailto:supittma@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" >>> >>> >>> that is my impression as well, talking to Dan on IRC; >>> ATM all is polling, but the sync-server will be >>> cable of doing WebSocket/SockJS, so "connected" >>> clients, can sync. >> Polling is MURDER on battery, performance, and >> "feel". WebSockets and SockJS are awesome ideas for >> a future implementation for "real time". >> >> >> As far as I understood it, the sync-server just started >> w/ polling (pure HTTP). I think that WebSocket/SockJS is >> not really that far away, in terms of 'future' >> >> >>> >>> Push should be really used for 'wake-up', instead >>> of changing real information; Also SimplePush >>> clients could not even integrate here (the protocol >>> just uses version (or timestamps) >> Yes. >> >> On the topic of Simple Push, you push a URL so in >> theory you could push >> /Documents/${collecitonName}/${id}/${rev_id} and >> have simple push setup to accept URLS formatted that >> way right? Or is it more limited than that? >> >> >> you can simply ONLY push a version number, that's it > I just reread things. It is worse than that. You can > (should) only push an increasing version number. So > anything checksum based will fail. > > > > best practice is 'timestamp' - that's all you can push over > to those devices > > > for a good reason Yeah. I keep forgetting how simple simplepush is. My original though on simple push was that a client to register as a listener for /Documents/Collections and it would receive pushes to /Documents/Collections/foo/bar. I was totally wrong :) This gives a much better context to everything that is also going on. you are now buying the real-time ?

> >> >> >> >> >>> >>> >>> >>> > 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(a)lists.jboss.org >>> <mailto:aerogear-dev@lists.jboss.org> >>> >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@lists.jboss.org> >>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> <mailto:aerogear-dev@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > <mailto:aerogear-dev@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 > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev