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 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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev