[aerogear-dev] Data Sync Thoughts

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] Data Sync Thoughts

Luke Holmquist
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



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf



On Tue, Jan 28, 2014 at 3:36 PM, Lucas Holmquist <[hidden email]> 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

+1
 



_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Luke Holmquist
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.)

Thoughts? Tomatoes?
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Luke Holmquist

On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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"

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
On 01/28/2014 10:48 AM, Lucas Holmquist wrote:

> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Luke Holmquist

On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:

> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.

this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
On 01/28/2014 10:58 AM, Lucas Holmquist wrote:

> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>
>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
Right.  I'm not saying lets do something complicated.  I'm saying lets
use GCM, iOS CM, and simple push to send notifications to tell the
client something.  In simplePush case it is "this data changed, get the
new stuff and update yourself".  In Android and iOS case it may be that
or it may be "here is new data".

In general, I am fine for getting a message saying something like
Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
data if necessary, update my local data, and send any updates.  That
SHOULD (I think) be doable with simplepush as well right?

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Corinne Krych
I think we still need the synchronisation mode in pull mode.

How are we going to deal with this use case with simple push:
UserA is offline update some data, then switch off his phone
Some other users update data
UserA open his app, he has missed some push notifications but still want to sync his app.

++
Corinne


On 28 January 2014 17:01, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>
>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
Right.  I'm not saying lets do something complicated.  I'm saying lets
use GCM, iOS CM, and simple push to send notifications to tell the
client something.  In simplePush case it is "this data changed, get the
new stuff and update yourself".  In Android and iOS case it may be that
or it may be "here is new data".

In general, I am fine for getting a message saying something like
Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
data if necessary, update my local data, and send any updates.  That
SHOULD (I think) be doable with simplepush as well right?

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Luke Holmquist
In reply to this post by Summers Pittman

On Jan 28, 2014, at 11:01 AM, Summers Pittman <[hidden email]> wrote:

> On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
>> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>>
>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
>> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
> Right.  I'm not saying lets do something complicated.  I'm saying lets
> use GCM, iOS CM, and simple push to send notifications to tell the
> client something.  In simplePush case it is "this data changed, get the
> new stuff and update yourself".  In Android and iOS case it may be that
> or it may be "here is new data".
>
> In general, I am fine for getting a message saying something like
> Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
> data if necessary, update my local data, and send any updates.  That
> SHOULD (I think) be doable with simplepush as well right?


not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for sync.

then we are relying on these 3rd party services,  

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Summers Pittman



On Tue, Jan 28, 2014 at 4:30 PM, Summers Pittman <[hidden email]> 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.

W/ "sync message" you mean something like a 'heads-up' from the server it has something new, instead of the concrete delta/diff ? 
 
4.  AG Synchronizer sends sync messages using Pipes

Like: "server, my local copy changed!" ?
 
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Luke Holmquist



On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <[hidden email]> wrote:

On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.

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)


 

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Summers Pittman



On Tue, Jan 28, 2014 at 4:54 PM, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Summers Pittman



On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>
>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
Right.  I'm not saying lets do something complicated.  I'm saying lets
use GCM, iOS CM, and simple push to send notifications to tell the
client something.  In simplePush case it is "this data changed, get the
new stuff and update yourself".  In Android and iOS case it may be that
or it may be "here is new data".

even iOS is _very_ limited in terms of payload. 

In Android you can push entire books :-), but not w/ iOS, nor w/ SimplePush
 

In general, I am fine for getting a message saying something like
Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
data if necessary, update my local data, and send any updates.  That
SHOULD (I think) be doable with simplepush as well right?

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

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Luke Holmquist



On Tue, Jan 28, 2014 at 5:41 PM, Lucas Holmquist <[hidden email]> wrote:

On Jan 28, 2014, at 11:01 AM, Summers Pittman <[hidden email]> wrote:

> On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
>> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>>
>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
>> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
> Right.  I'm not saying lets do something complicated.  I'm saying lets
> use GCM, iOS CM, and simple push to send notifications to tell the
> client something.  In simplePush case it is "this data changed, get the
> new stuff and update yourself".  In Android and iOS case it may be that
> or it may be "here is new data".
>
> In general, I am fine for getting a message saying something like
> Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
> data if necessary, update my local data, and send any updates.  That
> SHOULD (I think) be doable with simplepush as well right?


not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for sync.

then we are relying on these 3rd party services,


+1



 

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Matthias Wessendorf
On 01/28/2014 11:44 AM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 4:30 PM, Summers Pittman <[hidden email]> 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.

W/ "sync message" you mean something like a 'heads-up' from the server it has something new, instead of the concrete delta/diff ? 
 
4.  AG Synchronizer sends sync messages using Pipes

Like: "server, my local copy changed!" ?
Or, more specifically, "Here is new data"
 
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Matthias Wessendorf
On 01/28/2014 11:46 AM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <[hidden email]> wrote:

On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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".

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?


 

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


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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Matthias Wessendorf
On 01/28/2014 11:48 AM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 4:54 PM, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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;
No not really.  I mean what I said in the other email when you asked the same question ;)
The mobile push is really more for notification that "something" has changed. Clients than could ping the sync-server for latest value
Yes.  This ^^.  That is what my "ideal" will do for 1.0

 

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

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Matthias Wessendorf
On 01/28/2014 11:49 AM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>
>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
Right.  I'm not saying lets do something complicated.  I'm saying lets
use GCM, iOS CM, and simple push to send notifications to tell the
client something.  In simplePush case it is "this data changed, get the
new stuff and update yourself".  In Android and iOS case it may be that
or it may be "here is new data".

even iOS is _very_ limited in terms of payload. 

In Android you can push entire books :-), but not w/ iOS, nor w/ SimplePush
Android is still limited to 4K I think.

I am fine with designing around the limitations of SimplePush. 

 

In general, I am fine for getting a message saying something like
Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
data if necessary, update my local data, and send any updates.  That
SHOULD (I think) be doable with simplepush as well right?

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

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Matthias Wessendorf
In reply to this post by Summers Pittman



On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman <[hidden email]> wrote:
On 01/28/2014 11:46 AM, Matthias Wessendorf wrote:



On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <[hidden email]> wrote:

On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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



 



 

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


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


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] Data Sync Thoughts

Summers Pittman
In reply to this post by Luke Holmquist
On 01/28/2014 11:41 AM, Lucas Holmquist wrote:

> On Jan 28, 2014, at 11:01 AM, Summers Pittman <[hidden email]> wrote:
>
>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
>>> On Jan 28, 2014, at 10:54 AM, Summers Pittman <[hidden email]> wrote:
>>>
>>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <[hidden email]> 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.
>>> this makes sense,  but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers )
>> Right.  I'm not saying lets do something complicated.  I'm saying lets
>> use GCM, iOS CM, and simple push to send notifications to tell the
>> client something.  In simplePush case it is "this data changed, get the
>> new stuff and update yourself".  In Android and iOS case it may be that
>> or it may be "here is new data".
>>
>> In general, I am fine for getting a message saying something like
>> Documents/Schedules/1/${revision}.  Then I can check my revisions, fetch
>> data if necessary, update my local data, and send any updates.  That
>> SHOULD (I think) be doable with simplepush as well right?
>
> not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for sync.
> then we are relying on these 3rd party services,
That is a valid concern.

I think making our entire sync product based on polling is a bad thing.
(Battery, performance, etc etc etc).
I think making sync based on TCP sockets/WebSockets/SockJS is a good
thing, but it is past 1.0
I think making our sync product demand proprietary technology is a bad
thing, but I don't know of a service which is as easy as APNS or GCM for
iOS and Android devs.



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
123