[aerogear-dev] Sync data model comparison

[Summers Pittman]

On Thu 09 Jan 2014 01:43:42 AM EST, Bruno Oliveira wrote:
> Good morning Summers, it sounds like a fancy good idea. Out of curiosity do you know where such method was applied for real?
>
> Not advocating in favor of CouchDB, but might be interesting to look at: http://wiki.apache.org/couchdb/Replication_and_conflicts and http://guide.couchdb.org/draft/consistency.html#figure/6.
>
> One open question still in my mind. For the server side bits. Why not just make use of a provider? For example on SPS for data stores Dan have implemented something like this: https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores
>
> ps: I’m not against us implementing anything new.

One of the things about using a provider that I don't like is the 
"using a provider".  One of the things I hope sync to become is a 
collection of tools, utilities, and patterns that our developers can 
adopt to add in sync to their web apps without having to add extra 
services like couch, pouch, etc and without having to significantly 
alter their application.

HOWEVER, I am still reading up on / playing with Couch so don't count 
me out on thinking it is a good way to go forward; I just havn't seen 
any code to get the feel for how it will interact inside of AeroGear.  
It is entirely possible that it will be / can be one of the tools that 
we use for some of our sync solution.

>
> --
> abstractj
>
> On January 8, 2014 at 7:07:40 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
>>
>