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)

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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev