Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 78631 invoked from network); 17 Feb 2009 17:44:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Feb 2009 17:44:56 -0000 Received: (qmail 29691 invoked by uid 500); 17 Feb 2009 17:44:54 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 29652 invoked by uid 500); 17 Feb 2009 17:44:54 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 29641 invoked by uid 99); 17 Feb 2009 17:44:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Feb 2009 09:44:54 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jens@mooseyard.com designates 208.97.132.74 as permitted sender) Received: from [208.97.132.74] (HELO randymail-a12.g.dreamhost.com) (208.97.132.74) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Feb 2009 17:44:45 +0000 Received: from snej-mbp.mtv.corp.google.com (216-239-45-4.google.com [216.239.45.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by randymail-a12.g.dreamhost.com (Postfix) with ESMTP id 1CCCFA6F30 for ; Tue, 17 Feb 2009 09:44:24 -0800 (PST) Message-Id: <78154E1F-77C3-4F5F-B4A3-97B9EB2D6CF2@mooseyard.com> From: Jens Alfke To: user@couchdb.apache.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Any docs or specs on how replication works? Date: Tue, 17 Feb 2009 09:44:23 -0800 X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org I'd like to learn how CouchDB's replication protocol works. Not at the =20= implementation level (I don't read Erlang well enough for that!) but =20 are there any design docs that describe what's happening =20 architecturally? Conceptually, I can imagine it being based on an "_all_docs_by_seq" =20 query, where the pulling server remembers the last sequence ID it's =20 pulled in the past, grabs all the newer docs, and puts them to its =20 local database. Is there more to it than that? =97Jens=