[aerogear-dev] Sync data model comparison

[Bruno Oliveira]

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.

--  
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  
>