Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of maxosmail@gmail.com designates
 209.85.212.45 as permitted sender)
MIME-Version: 1.0
Sender: maxosmail@gmail.com
In-Reply-To: <D6831D11FC974DD9AB519572990939F5@zive.at>
References: <D6831D11FC974DD9AB519572990939F5@zive.at>
From: Max Ogden <max@maxogden.com>
Date: Thu, 28 Jul 2011 12:18:58 -0400
Message-ID: 
 <CAONf+LSE7-39kw3_ZjV3EexCZBiN6x1rVO5ysn=N5uUpQqv04Q@mail.gmail.com>
Subject: Re: Guys with deep knowledge about CouchDB Replication, I'd need your
 help :)
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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> 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-f=
unctionality against.
>
> http://tasks.substance.io (don't miss the sync button in the upper right =
corner)
> https://github.com/michael/data/blob/7729d41677e48bd5132119997dc0cff53522=
bb55/examples/tasks/public/javascripts/views/app.js
>
> It's currently just one way. It just writes changes to the server but doe=
s 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 updat=
es (other users might have updated them), and if yes, pull them in
> =C2=A0If conflicts occur the client/user decides how to resolve it (choos=
e 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 doi=
ng 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+revi=
sions to the server. The server (resp. Couch) should then check if there ar=
e updates for any of them. If yes, those nodes should be fetched and delive=
red to the client. Given that number of ID/revision pairs, what would be th=
e best way to check for updates? Or do you have any other ideas on how to d=
o 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 mor=
e 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 offli=
ne 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 develo=
pers who wan't to build offline apps. What do you think?
>
> Thanks!
>
> -- Michael
>