[aerogear-dev] Sync data model comparison

[Summers Pittman]

On Fri 17 Jan 2014 08:13:51 AM EST, Lucas Holmquist wrote:
> so i briefly looked at the spread sheet,  i'm concerned about having to keep 2 models on the client, especially on the mobile web,  since there is limited space( storage ) to work with as well as memory.  i wonder what the performance impact of this is?

Sounds like a good time for implement and measure :-p.

On a less snarky tone the answer is it depends.  At most you just 
double your storage, but part of the idea is also you have to be smart 
about what is being synced.  If the user isn't editing a document then 
you don't need to be maintaining your local shadow.

>
> it sounds cool though
> On Jan 8, 2014, at 4:07 PM, Summers Pittman <supittma at redhat.com> wrote:
>
>> So I'm not sure I see how the data model in the current sync spec helps
>> with syncing data.  Also the current spec draft is lacking a transport
>> format as well.
>>
>> I propose using the dual shadow data model described here:
>> https://neil.fraser.name/writing/sync/
>>
>> ## Data Model: and Transport:
>>
>> Client side each piece of data which is currently in active
>> synchronization (ie the client is sending AND receiving updates at the
>> same time) has a copy of her data which represents the current assumed
>> good synchronized state.  She also has the copy of the data she is
>> editing.  When she has finished her edit (for an use case specific
>> defined by the developer definition of finish) the system will generate
>> a diff based on the JSON representations of her shadow and her model.
>> The model will replace the shadow and a diff of her data as well as a
>> checksum of her data will be sent to the server for processing.
>>
>> Server side the server will maintain its own model of the shared data,
>> as well as shadows for each session currently sync the data. When it
>> receives a sync, the diff will be applied to the server's shadow of the
>> session which sent the diff.  If the diff merges cleanly and the
>> checksum of the server shadow matches the checksum in the transport,
>> then the server will update the canonical model of the data against what
>> was in the session's updated shadow.  The server will then diff all of
>> its sessions' shadows against its model and send out diff messages to
>> the clients.
>>
>> I've made a spreadsheet* where I follow one of QMX's sample applications
>> and step through a few workflows with my proposed data model.  (This is
>> the data model I use in the DevNexus sync demo and the real time text
>> demo).  I would welcome someone to implement the use case with QMX's
>> proposed data model.
>>
>> *
>> https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1
>>
>> wdyt?  Who would mind doing the data flow for the other model?
>> _______________________________________________
>> 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