Re: [aerogear-dev] Data Sync Thoughts

On Jan 28, 2014, at 1:24 PM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman 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? >> >> 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. >> 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.) > The thing I have against all this is its curse and its blessing at the > same time. I prefer to ship small-ish tools that the developer can use > the way she wants instead of a full-blown-zomg-unicorns full-stack > solution. > > Even the pipeline API requires some level of buy-in, and I really wish > our DataSync API to be as decoupled as possible from the other parts. my initial stab at the JS lib for data sync had no dependency on the other parts, ( expect for maybe Notifier ) the idea is to be able to have the "sync" lib, "mixin" with DataManager,

> This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > > If we start with a fully integrated solution, it will be awesome, if we > have buy-in from the developer. And we all know that things not > necessarily go this way with OSS projects, hence my kerfuffle against > increasing sync's scope for 1.0. > > What's the MVP for the sync to be a good foundation for all the shiny > bits? That's the question I want to have a good answer for. > >> Thoughts? Tomatoes? >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev