couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Peer Commit
Date Wed, 18 Feb 2009 23:09:11 GMT
I don't know the literature, but I have an idea for a shared
data-space across peer nodes (not in a cluster).

A replication helper, which tracks all known replicas, and their last
successfully replicated sequence num can provide to the user a list of
remote nodes that have knowledge of each update.

I think this works better with POST than GET replication... but by
logging GET replications we could have a rough idea as well.

If we track sequence id progress of all known replicas, we know with
what confidence local updates have been propagated to the network.

We can add secure messaging eventually, but for starters even a good
public data flow can get us a long way. The next step here is

It makes sense to me that distributed applications should expose their
replication state to the end user. Peer commit, or maybe eventual peer
commit, on an individual document update basis, does not make any
guarantees beyond the most basic, but still provides the ability to
publish content to a wide audience via a distributed network.

Example: When a user in a p2p mesh can see that N remote nodes are
keeping roughly up to date with her blog, it gives the proper
granularity of feedback. In the CouchDB Web, we don't count page hits,
we count replication streams.

I think it's the simplest metaphor, and avoids false abstractions like
bulk commits and order guarantees.


Chris Anderson

View raw message