Great! I have the same need with you. Except I'm doing it on Android, not browser. I also posted a question about this on quora before.
http://www.quora.com/How-can-I-implement-a-CouchDB-replicator 2011/7/29 Michael Aufreiter <[email protected]> > > Nice. Having a look at it. > > It really depends on how much functionality you wanna delegate to the client. > In my opinion, in most cases you wan't to keep the amount of local data low. > That's why I'll probably use localstorage to memoize a complete snapshot of > the current graph. Once you reload the page all data is loaded into memory > again (restored) and you can query it as usual (using Data.Graph#find). So in > my case I'd rather wanna use just LocalStorage without employing indexedDB > etc. as local views(map-reduce etc) wouldn't be an requirement here. But what > I need to solve is the replication thing. > > > On Thursday, July 28, 2011 at 6:18 PM, Max Ogden wrote: > > > 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] > > (mailto:[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 (http://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 > > -- - sleepnova
