incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <da...@vancouvering.com>
Subject Peer to peer replication
Date Sat, 07 Mar 2009 09:58:27 GMT
Hi, all.  I've been chewing on the uses of CouchDB, and it seems it could be
very useful for peer-to-peer document sharing between *individuals* - a
community of collaborators on the web.

For example, a community wants to collaborate on a set of documents, but
would rather not have to go through setting up some kind of web site.  They
just want to set up a folder that each member sees on their local machine
and then have this folder be shared amongst the community.

CouchDB seems very close to being the perfect technology for this.  But I do
have some questions... (and potentially more as I chew on this further).

- What protocol is used for replication across nodes?  I'm assuming it's
HTTP but just checking.  In a peer-to-peer system, this sounds like it means
that each participant has to open up their HTTP port for replication to
work.  Is that correct?

- A community collaborating on a document would probably like to be able to
view older versions, view differences between versions, revert to older
versions, etc.  I couldn't immediately find if CouchDB can retain older
versions indefinitely, or if older versions get "cleaned up" over time.  I
suspect that the multi-version support in CouchDB isn't really intended for
that usage - it's more for lock-free writes.  I suspect that if I wanted to
have this kind of functionality I would have to layer those semantics on top
of CouchDB using one document for each revision and providing my own diff
functionality, etc.   Is that right?

Thanks,

David



-- 
David W. Van Couvering

I am looking for a senior position working on server-side Java systems.
 Feel free to contact me if you know of any opportunities.

http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message