incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sleepnova <wanpee...@gmail.com>
Subject Re: Guys with deep knowledge about CouchDB Replication, I'd need your help :)
Date Sat, 30 Jul 2011 10:30:56 GMT
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 <ma@zive.at>
>
> 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 <ma@zive.at (mailto:ma@zive.at)>
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

Mime
View raw message