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 aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; 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 >>> 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 > > _______________________________________________ > 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

On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma(a)redhat.com&gt; 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&gt; 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 >>>>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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

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

On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; 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 >>> 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 > > _______________________________________________ > 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

On Jan 28, 2014, at 11:01 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma(a)redhat.com&gt; 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&gt; 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 >>>>>> 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 >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> 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" 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 >> 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

On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:54 AM, 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. > 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 >>>>> 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 > > _______________________________________________ > 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

On Jan 28, 2014, at 11:01 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma(a)redhat.com&gt; 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&gt; 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 >>>>>> 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 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 01/28/2014 11:41 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 11:01 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma(a)redhat.com&gt; 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&gt; 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 >>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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

On Tue, Jan 28, 2014 at 6:14 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 11:41 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 11:01 AM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> On Jan 28, 2014, at 10:54 AM, 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. >>> 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 regarding 1.0 - I am not even sure what that version should be done; but for me (personal thought), I (again, personally) have serious doubts that the first sync offerings (March/April?) will be the ones labeled as '1.0.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 >>>>>>> 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 >>> _______________________________________________ >>> 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

On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> >> On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; >> 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 I just reread things. It is worse than that. You can (should) only push an increasing version number. So anything checksum based will fail.

> > > > > >> >> > 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 >> >> 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 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 listaerogear-dev@lists.jboss.orghttps://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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> 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" >> >> >> 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 I just reread things. It is worse than that. You can (should) only push an increasing version number. So anything checksum based will fail. best practice is 'timestamp' - that's all you can push over to those devices for a good reason

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

On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > > On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >> >> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> >>> 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" >>> >>> >>> 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 > I just reread things. It is worse than that. You can > (should) only push an increasing version number. So > anything checksum based will fail. > > > > best practice is 'timestamp' - that's all you can push over > to those devices > > > for a good reason Yeah. I keep forgetting how simple simplepush is. My original though on simple push was that a client to register as a listener for /Documents/Collections and it would receive pushes to /Documents/Collections/foo/bar. I was totally wrong :) This gives a much better context to everything that is also going on. you are now buying the real-time ?

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

On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >> >> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >>> <supittma(a)redhat.com <mailto:supittma@redhat.com>> >>> wrote: >>> >>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas >>>> Holmquist <lholmqui(a)redhat.com >>>> <mailto:lholmqui@redhat.com>> 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" >>>> >>>> >>>> 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 >> I just reread things. It is worse than that. You >> can (should) only push an increasing version >> number. So anything checksum based will fail. >> >> >> >> best practice is 'timestamp' - that's all you can push >> over to those devices >> >> >> for a good reason > Yeah. I keep forgetting how simple simplepush is. > > My original though on simple push was that a client to > register as a listener for /Documents/Collections and it > would receive pushes to /Documents/Collections/foo/bar. I > was totally wrong :) > > This gives a much better context to everything that is also > going on. > > > you are now buying the real-time ? I still say skipping push initiated sync and going straight to real time isn't a great first release idea. What I am buying now is [polling]->[push initialed]->[beefing up push adapters to include good mqtt and websocket]->[real time] I doubt that push is (always) needed - not sure every mobile _really_ wants to receive a notification "something is new". If an application relies on push in order to function it is fundamentally broken

In my earlier real time text demo I wrote a websocket push adapter so there exists code to help with that hump. > > > >> >>> >>> >>> >>> >>>> >>>> >>>> >>>> > 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 >>>> >>>> >>>> >>>> >>>> -- >>>> 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 <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 <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 >> >> >> >> >> -- >> 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 <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 <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

On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > >> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: >>> >>>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: >>>> >>>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist <lholmqui(a)redhat.com >>>>> > wrote: >>>>> >>>>>> >>>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; >>>>>> 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 >>>> >>>> I just reread things. It is worse than that. You can (should) only >>>> push an increasing version number. So anything checksum based will fail. >>>> >>> >>> >>> best practice is 'timestamp' - that's all you can push over to those >>> devices >>> >> >> for a good reason >> >> Yeah. I keep forgetting how simple simplepush is. >> >> My original though on simple push was that a client to register as a >> listener for /Documents/Collections and it would receive pushes to >> /Documents/Collections/foo/bar. I was totally wrong :) >> >> This gives a much better context to everything that is also going on. >> > > you are now buying the real-time ? > > I still say skipping push initiated sync and going straight to real > time isn't a great first release idea. > > What I am buying now is [polling]->[push initialed]->[beefing up push > adapters to include good mqtt and websocket]->[real time] > I doubt that push is (always) needed - not sure every mobile _really_ wants to receive a notification "something is new". If an application relies on push in order to function it is fundamentally broken Well that depends.

If the purpose of the application is to get updates on non critical data then push is a fundamental part of the apps identity. Polling is too low and frequent polling is too wasteful. If the application just has to update once every few hours then polling is just peachy. There is no reason we can't have multiple adapters, some which need push, some which need real time bidirecitonal channels, and some which just need to get data a few times a day. A good API can hide all of these details and let a dev pick/choose/implement what she needs at design time. > > In my earlier real time text demo I wrote a websocket push adapter so > there exists code to help with that hump. > > > > > >> >> >> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> > 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 >>>>>> >> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 listaerogear-dev@lists.jboss.orghttps://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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

On Tue, Jan 28, 2014 at 10:48:14AM -0500, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > i thought for a 1.0 we weren't thinking about "realtime" Yep, and I'm still against realtime for 1.0

On Tue, Jan 28, 2014 at 6:53 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman > <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman >> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >> >> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >>> <supittma(a)redhat.com <mailto:supittma@redhat.com>> >>> wrote: >>> >>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers >>>> Pittman <supittma(a)redhat.com >>>> <mailto:supittma@redhat.com>> wrote: >>>> >>>> On 01/28/2014 11:46 AM, Matthias >>>> Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas >>>>> Holmquist <lholmqui(a)redhat.com >>>>> <mailto:lholmqui@redhat.com>> 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" >>>>> >>>>> >>>>> 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 >>> I just reread things. It is worse than that. >>> You can (should) only push an increasing >>> version number. So anything checksum based >>> will fail. >>> >>> >>> >>> best practice is 'timestamp' - that's all you can >>> push over to those devices >>> >>> >>> for a good reason >> Yeah. I keep forgetting how simple simplepush is. >> >> My original though on simple push was that a client to >> register as a listener for /Documents/Collections and it >> would receive pushes to /Documents/Collections/foo/bar. >> I was totally wrong :) >> >> This gives a much better context to everything that is >> also going on. >> >> >> you are now buying the real-time ? > I still say skipping push initiated sync and going straight > to real time isn't a great first release idea. > > What I am buying now is [polling]->[push initialed]->[beefing > up push adapters to include good mqtt and websocket]->[real time] > > > I doubt that push is (always) needed - not sure every mobile > _really_ wants to receive a notification "something is new". > > If an application relies on push in order to function it is > fundamentally broken Well that depends. well, on iOS a user of an app can say "No" to the feature of receiving push notifications. If the app, using our sync bits, does NOT work when no push is available, the api is broken. Push, as part of the sync, should be optional, not required. for the apple app-store guidelines it's similar: if an app only works when it is allowed to receive push-notifications: You dont get an approval.

Push optional to wake-up: yes - but that's not really sync :) that's more a trigger, which may cause the app connecting to our real-time service on the sync server

If the purpose of the application is to get updates on non critical data then push is a fundamental part of the apps identity. Polling is too low and frequent polling is too wasteful. If the application just has to update once every few hours then polling is just peachy. There is no reason we can't have multiple adapters, some which need push, some which need real time bidirecitonal channels, and some which just need to get data a few times a day. A good API can hide all of these details and let a dev pick/choose/implement what she needs at design time. > > > In my earlier real time text demo I wrote a websocket push > adapter so there exists code to help with that hump. > > >> >> >> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> > 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 <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 <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 >>> >>> >>> >>> >>> -- >>> 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 <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 <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 <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

On Tue, Jan 28, 2014 at 10:48:14AM -0500, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:30 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > i thought for a 1.0 we weren't thinking about "realtime" Yep, and I'm still against realtime for 1.0 -- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

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

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

On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: On 01/28/2014 11:11 AM, Corinne Krych wrote: > 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. That is the magic of Push systems. He gets the messages when he comes online. Device A and B and Server have data with a checksum of 42. Device A goes offline. Device A changes its data and has a checksum of 64. Device B changes its data and has a checksum of 192. Device B sends the expected server checksum of 42 and its new data to the server. Server accepts B's Data, updates its checksum to 192, and sends a message to all Devices ( in this case just A) sending the data does not work via 'mobile push' - we need something like 'real-time' for that sending;

Device B and Server go on a long date, but things don't work out and they end up splitting the check 50/50. Device B is annoyed because she only got a salad but Server got the Surf and Turf. Device A comes online and receives a message from the server. Device A notices the server's checksum data is a change from 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and fires a message to the User of Device A to resolve the data. User A resolves the data and Device A sends the merged data to the server. Device B gets a message of new data and updates to what the server has. > > ++ > Corinne > > > On 28 January 2014 17:01, Summers Pittman <supittma(a)redhat.com > <mailto:supittma@redhat.com>> wrote: > > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:54 AM, 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. > > 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 > >>>>> 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 > > > > _______________________________________________ > > 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

On 01/29/2014 03:08 AM, Matthias Wessendorf wrote: On Tue, Jan 28, 2014 at 7: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. > I agree on the decoupling. That's pretty much what the iOS lib does today: Only dependency is AFNetworking; The JS bits are similar, nothing is weaved into the existing APIs there as well > This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > I think we somewhat agreed already on a document based model, now it looks like several POCs are build to integrate w/ our sync-server bits Just out of curiosity, what other models are there?

[Also I think it will be better to say metadata + object model instead of document. Document is 1) very generic and 2) has very different definitions depending on what we are thinking]

> > 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. > So, what will the scope be? And will there be a 1.0 ? ^^ This. One of the things we have been failing at doing (and failing hard) is defining a scope for sync.

I am not really sure that we will have a 1.0.0 in the next few month. -Matthias > 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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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

My 2 non technical cents, I really think we should separate "push" from "sync" and integrate later, bet on simple. In my opinion we are just adding one more level of complexity. For example: would be perfect to add digital signatures, encrypted data for that storage and all the sick things from security. But that would add an extra level of complexity which would lead us to several months of development.

Is just my opinion, but if you guys think that we REALLY need Push, MVP or whatever atm, that's fine. On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: > > > > On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman <supittma(a)redhat.com&gt;wrote: > >> On 01/28/2014 11:11 AM, Corinne Krych wrote: >> >> 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. >> >> That is the magic of Push systems. He gets the messages when he comes >> online. >> >> Device A and B and Server have data with a checksum of 42. >> Device A goes offline. >> Device A changes its data and has a checksum of 64. >> Device B changes its data and has a checksum of 192. >> Device B sends the expected server checksum of 42 and its new data to >> the server. >> Server accepts B's Data, updates its checksum to 192, and sends a >> message to all Devices ( in this case just A) >> > > sending the data does not work via 'mobile push' - we need something like > 'real-time' for that sending; > > >> >> Device B and Server go on a long date, but things don't work out and >> they end up splitting the check 50/50. Device B is annoyed because she >> only got a salad but Server got the Surf and Turf. >> >> Device A comes online and receives a message from the server. >> Device A notices the server's checksum data is a change from 42 -> 192 >> and not 42 -> 64. Thus its copy is out of sync and fires a message to the >> User of Device A to resolve the data. >> User A resolves the data and Device A sends the merged data to the >> server. >> Device B gets a message of new data and updates to what the server has. >> >> >> >> ++ >> Corinne >> >> >> On 28 January 2014 17:01, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> > On Jan 28, 2014, at 10:54 AM, Summers Pittman <supittma(a)redhat.com&gt; >>> 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&gt; >>> 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 >>> >>>>> 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 >>> >>> _______________________________________________ >>> >>> 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 >>> > >>> > _______________________________________________ >>> > 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 >>> >> >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 >> > > > > -- > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

> Then what we are talking about is no longer sync. It is revision control.

On Wed, Jan 29, 2014 at 09:14:20AM -0500, Summers Pittman wrote: > On 01/29/2014 07:43 AM, Bruno Oliveira wrote: >> My 2 non technical cents, I really think we should separate "push" from >> "sync" and integrate later, bet on simple. In my opinion we are just >> adding one more level of complexity. >> >> For example: would be perfect to add digital signatures, encrypted data >> for that storage and all the sick things from security. But that would add >> an extra level of complexity which would lead us to several months of >> development. >> >> Is just my opinion, but if you guys think that we REALLY need Push, MVP or >> whatever atm, that's fine. > Then what we are talking about is no longer sync. It is revision control. Well, what if I the developer want to download the files from Dropbox API and do the sync locally? (YNAB app works like this) It still is sync, at least from my POV

>> >> >> On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf <matzew(a)apache.org >> <mailto:matzew@apache.org>> wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman >> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >> >> On 01/28/2014 11:11 AM, Corinne Krych wrote: >>> 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. >> That is the magic of Push systems. He gets the messages when >> he comes online. >> >> Device A and B and Server have data with a checksum of 42. >> Device A goes offline. >> Device A changes its data and has a checksum of 64. >> Device B changes its data and has a checksum of 192. >> Device B sends the expected server checksum of 42 and its new >> data to the server. >> Server accepts B's Data, updates its checksum to 192, and >> sends a message to all Devices ( in this case just A) >> >> >> sending the data does not work via 'mobile push' - we need >> something like 'real-time' for that sending; >> >> >> Device B and Server go on a long date, but things don't work >> out and they end up splitting the check 50/50. Device B is >> annoyed because she only got a salad but Server got the Surf >> and Turf. >> >> Device A comes online and receives a message from the server. >> Device A notices the server's checksum data is a change from >> 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and >> fires a message to the User of Device A to resolve the data. >> User A resolves the data and Device A sends the merged data to >> the server. >> Device B gets a message of new data and updates to what the >> server has. >> >> >>> >>> ++ >>> Corinne >>> >>> >>> On 28 January 2014 17:01, Summers Pittman >>> <supittma(a)redhat.com <mailto:supittma@redhat.com>> wrote: >>> >>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> > On Jan 28, 2014, at 10:54 AM, 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. >>> > 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 >>> >>>>> 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 >>> > >>> > _______________________________________________ >>> > 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 <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> >> >> _______________________________________________ >> 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