couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus Trainer <>
Subject Re: why erlang?
Date Mon, 16 Aug 2010 19:25:40 GMT
I believe the greatest advantage of HTTP over other more efficient
protocols is that you can easily integrate it with any other web stuff.
For example browsers.

You can build CouchApps ( without having
any layer in between. As an example, see Toast
( It uses CouchDB's continuous
replication in order to build a super-simple chat application. All you
need therefor is CouchDB and a browser.

Of course, there might be way more efficient protocols to support P2P
replication, but the tradeoff is reasonable, I think.

I wonder if under certain circumstances, the HTTP overhead is
negligible, anyway. For example, once you have an open socket and listen
on the changes feed (that's what Toast does), you normally won't close
the connection intentionally. Instead all the data is streamed, and
there is no overhead through HTTP headers anymore.

- Klaus

On Mon, 2010-08-16 at 14:55 -0400, Miles Fidelman wrote:
> Noah Slater wrote:
> > On 16 Aug 2010, at 19:22, Miles Fidelman wrote:
> >
> >    
> >> I guess I'm just a little surprised that the replication features seem to be
independent of Erlang's underlying inter-node communications capabilities.
> >>      
> > I'm going to hazard an answer here. CouchDB is, primarily, a database built for
the web. That means speaking HTTP. All communication between CouchDB and other agents is,
and should be, done via that route. There has been talk, in the past, about communicating
with CouchDB from within Erlang itself, but that is not a priority for the main project. Pushing
things over HTTP lets us take advantage of 30 years worth of caching, proxying, authentication,
and other Web-stack middleware.
> True, but... HTTP is not necessarily an ideal protocol for many-to-many 
> replication, nor is HTTP 30 years old.  There's a lot of experience that 
> dates back further - for example, UUCP is probably a much better 
> protocol for large-scale eventual consistency than the pair-wise 
> approach currently used by CouchDB.
> Miles

View raw message