[aerogear-dev] Data Sync Thoughts

[Matthias Wessendorf]

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

> On 01/28/2014 01:24 PM, Douglas Campos 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.
> >
> > 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.
> I shifting into Java speak here for a second because it is easier for me.
>
> What I want as a MVP is a good Interface for the bit of sychronization
> the developer will interact with. Everything else is an implementation
> detail that we can write and rewrite until the checks stop cashing :)
>
> The data model is one part of this, it is how the code which implements
> the Interface will see its own data and also what it will send to the
> server.
>
> The how of that is whatever.  It can use a pipe, it can send the data
> over a websocket.  Both are easily done.
>
> The next implementation detail is how does remote data get on the
> device?  Does the server send via a websocket updated data (again based
> on our data model enveolope), does it send a ping message (via a push
> service) and the client pulls down new data?  Does the client poll?  It
> doesn't matter as long as our public interfaces can be forced to do all
> of them in a non insane way.
>

I think we all agree that we need some 'interface' like that and that the
actual details are good hidden by the actual implementation


>
> I think we are saying the same thing, at least I didn't hear you say
> anything that made me say "wat?!".
>
>
> >> 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
>



-- 
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/20140129/ddd10696/attachment.html