[aerogear-dev] Data Sync Thoughts

Wed Jan 29 07:49:55 EST 2014

On Wed, Jan 29, 2014 at 1:43 PM, Bruno Oliveira <bruno at abstractj.org> 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.
>

+1

>
> 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 at apache.org>wrote:
>
>>
>>
>>
>> On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman <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;
>>
>>
>>>
>>> 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> 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>
>>>> 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>
>>>> 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
>>>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >>>> _______________________________________________
>>>> >>>> aerogear-dev mailing list
>>>> >>>> aerogear-dev at lists.jboss.org
>>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >>> _______________________________________________
>>>> >>> aerogear-dev mailing list
>>>> >>> aerogear-dev at lists.jboss.org
>>>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >> _______________________________________________
>>>> >> aerogear-dev mailing list
>>>> >> aerogear-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>> >
>>>> > _______________________________________________
>>>> > aerogear-dev mailing list
>>>> > aerogear-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> 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
>>
>
>
>
> --
>
> --
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
>
> _______________________________________________
> aerogear-dev mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/61b35ffa/attachment-0001.html 