On Tue, Mar 26, 2013 at 10:27 PM, Jens Alfke <[email protected]> wrote:
> The replication protocol is interactive, so you can’t do things the same > way. For instance, a push replication first sends a _revs_diff request to > tell the remote server which new revisions it has that the remote _might_ > be interested in; then the remote responds by listing the subset of those > revisions that it doesn’t have yet, and what prior revisions of those > documents it does have. Then the source PUTs the revisions one by one. > This is really, really helpful. Thanks! You could write something that would do this in a less-optimal > non-interactive way. It would remember the last time it synced to the > target, gather up all the revisions that have happened since that sequence, > and bundle them up into a file. It would work fairly well if the target > server only replicates with the source server, i.e. it has no way to get > these replications from somewhere else. If you have a more complex set of > replications, then the source can end up sending way too much stuff because > the target may already have gotten those same revisions from somewhere else. > I think that's just a fact of life for my application. In a worst case, two different sources could want to replicate to a target at the same time, before the target checks for new messages. In this case, there's no way to avoid both sources uploading messages. > I'm looking for > > more information on how to build something that does that. So far all > I've > > found is http://comments.gmane.org/gmane.comp.db.couchdb.user/164. > > I’ve documented the replication protocol here: > > https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replication-Algorithm > The APIs that the replicator calls are all documented in the CouchDB wiki > (partly because I made sure to add documentation for the ones that weren’t > documented as I ran into them): > http://wiki.apache.org/couchdb/Complete_HTTP_API_Reference > Thank you so much for your work documenting this. Ethan
