[aerogear-dev] Data Sync Thoughts

Summers Pittman supittma at redhat.com
Wed Jan 29 03:31:02 EST 2014


On 01/29/2014 03:03 AM, Matthias Wessendorf wrote:
>
>
>
> On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman <supittma at redhat.com 
> <mailto:supittma at 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;
Well it does work with GCM.  In this example I was specifically thinking 
about using a Pipe to send data.  Honestly that is an implementation 
detail and can be hand waved in any number of ways.
>
>
>     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 at redhat.com
>>     <mailto:supittma at redhat.com>> wrote:
>>
>>         On 01/28/2014 10:58 AM, Lucas Holmquist wrote:
>>         > On Jan 28, 2014, at 10:54 AM, Summers Pittman
>>         <supittma at redhat.com <mailto:supittma at redhat.com>> wrote:
>>         >
>>         >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote:
>>         >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman
>>         <supittma at redhat.com <mailto:supittma at 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 at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>         >>>> _______________________________________________
>>         >>>> aerogear-dev mailing list
>>         >>>> aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>         >>> _______________________________________________
>>         >>> aerogear-dev mailing list
>>         >>> aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>         >> _______________________________________________
>>         >> aerogear-dev mailing list
>>         >> aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>         >
>>         > _______________________________________________
>>         > aerogear-dev mailing list
>>         > aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>         _______________________________________________
>>         aerogear-dev mailing list
>>         aerogear-dev at lists.jboss.org
>>         <mailto:aerogear-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     aerogear-dev mailing list
>>     aerogear-dev at lists.jboss.org  <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
> -- 
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/4d3d9ace/attachment-0001.html 


More information about the aerogear-dev mailing list