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 (http://couchapp.org/page/index) without having any layer in between. As an example, see Toast (http://github.com/jchris/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 >
