I had a look into data.js and its tasks example. I love the direction it's heading to, great work!
I think the way you've implemented sync by posting all local document IDs is not very elegant though. I'm still new to Couch, but I think Couch makes use of the _change feed for its replication and I think you should do it, too. For the »Tasks« example, I'd start by generating something like an »account_id« (UUID) and then save each doc with an »account_id« attribute. Then I'd ask for all changes since the last time I asked, filtered by this »account_id« Does that make sense? On Mon, Aug 1, 2011 at 4:11 PM, Michael Aufreiter <[email protected]> wrote: > Thanks. Will investigate that. However here's what I've got so far > (involving localstorage): > > http://substance.io/#michael/offline-applications-with-datajs > > -- Michael > On Tuesday, August 2, 2011 at 12:29 AM, Randall Leeds wrote: > > On Fri, Jul 29, 2011 at 04:12, Michael Aufreiter <[email protected] (mailto: > [email protected])> wrote: > > > > > > 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. > > > > To solve replication and safely allow the application to be used > > across tabs you need indexedDB because it has transactions. > > > > Let me break that deduction down: > > Incremental replication requires a restart-able changes feed. A > > changes feed requires an index of updates order by time/sequence > > number. A sequence index that's kept in sync with the index of > > documents ordered by name requires changes to two indexes in an atomic > > transaction or race conditions are possible. > > > > If you're not worried about replicating incrementally or you're not > > worried about the possibility of race conditions (e.g., concurrent > > access by multiple tabs) you might be able to use LocalStorage, > > otherwise you'll need IndexedDB. > > > > Since PouchDB aims to be a robust and general-purpose implementation > > of CouchDB it uses IndexedDB. > > > > -Randall > > > > > > > > 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 > >
