incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject [PROPOSAL] Capability identification
Date Tue, 04 Jun 2013 22:40:35 GMT
Today, if I GET http://localhost:5984/ , I get:

Apache Software Foundation"}}

If I GET from , I get:


And if I GET , I get:


I believe I get further still different responses from Pouch and Touch
and other CouchDB-alikes, provided they even have an equivalent of
GET /.

Long ago, in a galaxy far far away, the developers of Internet Relay
Chat daemons faced a similar problem. While they were bound by a single
RFC (and later, its twin), each developer wanted to extend the program
in interesting and unique ways. Some of those features became
commonplace and built a shared understanding, others were unique
capabilities of specific implementations, and yet others indicated
specific incompatibilities introduced for nefarious purposes.

While the sordid history of the IRC protocol is a topic for drinks after
a meetup some night, one lesson learned has proved exceedingly useful:
the CAPAB string. Documented in the TS6 specification[1] but universally
adopted, server-to-server CAPAB/PROTOCTL provided a negotiation of both
implemented functionality as well as services offered. A further
extension was created for client-to-server capabiliity negotiation
as a draft RFC[2][4] and is also widely implemented.

To make this more tangible, reference this list[3] of IRC server
CAPABilities. If you've ever used IRC, and especially different IRC
networks, you should be able to intuitively understand how this up-front
negotiation helps simplify server-to-server connection negotiation.


I think CouchDB should extend its identification in the root-level
document with a capability advertisement. This would help prevent the
current anti-patterns in production use of CouchDB:

  1. Client library negotiation based exclusively on "compatibility
     with >= version of Apache CouchDB," which is nebulously documented
     at best.

  2. Provide a clear means by which CouchDB plugins and CouchDB-alike
     services can advertise their availability.

  3. Provide a way for alternate implementations of similar
     functionality to indicate interoperability.

  4. Possibly simplify the replicator (though this is a special case of
     1 and 2 above).

I've gotten no further than this in my thinking yet; I didn't want to
start implementation before folks had a chance to say whether they
thought it'd be a good idea or not.


Joan Touzet | | wohali everywhere else

View raw message