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 peer-discovery. 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 -- Chris Anderson http://jchris.mfdz.com
