beginnings of an html5 couch: https://github.com/mikeal/pouchdb
it would be great to get @mikeal and @tilgovi to chime in on this thread as they were writing the replicator for that On Thu, Jul 28, 2011 at 11:48 AM, Michael Aufreiter <[email protected]> wrote: > I'm currently working on a complete data-persistence solution for offline > apps, involving CouchDB and Data.js. I already introduced Data.js here at > this mailing list the other day, but here's a link again: > > http://substance.io/#michael/data-js > > I've setup a cleanroom example (tasks) that I want to test the new > sync-functionality against. > > http://tasks.substance.io (don't miss the sync button in the upper right > corner) > https://github.com/michael/data/blob/7729d41677e48bd5132119997dc0cff53522bb55/examples/tasks/public/javascripts/views/app.js > > It's currently just one way. It just writes changes to the server but does > not pull in node-updates. Now this should change. > > The algorithm for a bi-directional sync I have in mind looks like so: > > 1. Pull: For all nodes I have in my local graph, check if there are updates > (other users might have updated them), and if yes, pull them in > If conflicts occur the client/user decides how to resolve it (choose a > revision or merge it) > > 2. Push: Write all local dirty nodes to the server > > If that succeeded, the sync is complete. Usually if there's not much time > between the pull and the push it's unlikely to run into conflicts when doing > the push. > > However I'm asking myself how CouchDB replication is implemented -- maybe I > can re-use some of the concepts. > > In order to perform the Pull, I thought about sending a list of > ID's+revisions to the server. The server (resp. Couch) should then check if > there are updates for any of them. If yes, those nodes should be fetched and > delivered to the client. Given that number of ID/revision pairs, what would > be the best way to check for updates? Or do you have any other ideas on how > to do the pull? > > An implication of this scenario is that application developers should do > their best to keep the local graph rather small (the bigger it gets the more > overhead you have when doing the push, also more memory is used). However > this should suit a lot of scenarios (like in my case making possible offline > editing of Substance.io documents) > > Would be great if some of you could help me out a bit here. I think such a > framework (Data.js+Couch) would be a great benefit for application developers > who wan't to build offline apps. What do you think? > > Thanks! > > -- Michael >
