Re: [aerogear-dev] Data Sync Thoughts

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