Re: [aerogear-dev] Data Sync Thoughts

On Tue, Jan 28, 2014 at 4:54 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 10:48 AM, Lucas Holmquist 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" 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. You mean using Mobile Push to send actual content? Hrm, I guess that does not work w/ SimplePush;

The mobile push is really more for notification that "something" has changed. Clients than could ping the sync-server for latest value

> >> 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 _______________________________________________ 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