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/datast... ps: I’m not against us implementing anything new.

-- abstractj On January 8, 2014 at 7:07:40 PM, Summers Pittman (supittma(a)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-dGhESFU5R1BSWTF3... > > wdyt? Who would mind doing the data flow for the other model? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >

Makes sense, I think that’s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle.

-- abstractj On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma(a)redhat.com) wrote: >> 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.

after playing with dan's server a bit, a question has popped up. lets say a user has 10 pieces of data, is this considered 1 "document", so like this: { id: "1234567890-0987654321-1234567890", rev: "12345678909876543456787654", content: [ { ... }, { ... } ] //make believe there are 10 things there } or is each piece of data a "document", and each piece has its own id and revision? I think i like the first option, but i'm not sure On Jan 9, 2014, at 11:07 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > On Thu 09 Jan 2014 11:06:26 AM EST, Bruno Oliveira wrote: >> Makes sense, I think that’s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle. > > Yup, just got Danbev's server up and running. I'll see what happens :) > >> >> -- >> abstractj >> >> On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma(a)redhat.com) wrote: >>>> 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. >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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?

it sounds cool though On Jan 8, 2014, at 4:07 PM, Summers Pittman <supittma(a)redhat.com&gt; 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-dGhESFU5R1BSWTF3... > > wdyt? Who would mind doing the data flow for the other model? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev