Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: error (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [PROPOSAL] Capability identification
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <20130604224035.GA31324@atypical.net>
Date: Wed, 5 Jun 2013 20:36:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6F634DD-CEA2-4DB1-9854-DCEC8A42E9EB@apache.org>
References: <20130604224035.GA31324@atypical.net>
To: dev@couchdb.apache.org

+1, excellent proposal.

On Jun 5, 2013, at 00:40 , Joan Touzet <wohali@apache.org> wrote:

> Today, if I GET http://localhost:5984/ , I get:
>=20
>  =
{"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"=
1.3.0","vendor":{"version":"1.3.0","name":"The
> Apache Software Foundation"}}
>=20
> If I GET from http://mozauto.iriscouch.com/ , I get:
>=20
>  =
{"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"=
1.3.0","vendor":{"version":"1.3.0r1","name":"Iris
> Couch"}}
>=20
> And if I GET http://wohali.cloudant.com/ , I get:
>=20
>  {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"}
>=20
> I believe I get further still different responses from Pouch and Touch
> and other CouchDB-alikes, provided they even have an equivalent of
> GET /.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> ---
>=20
> 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:
>=20
>  1. Client library negotiation based exclusively on "compatibility
>     with >=3D version of Apache CouchDB," which is nebulously =
documented
>     at best.
>=20
>  2. Provide a clear means by which CouchDB plugins and CouchDB-alike
>     services can advertise their availability.
>=20
>  3. Provide a way for alternate implementations of similar
>     functionality to indicate interoperability.
>=20
>  4. Possibly simplify the replicator (though this is a special case of
>     1 and 2 above).
>=20
> 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.
>=20
> [1]:
> =
https://github.com/grawity/irc-docs/blob/master/server/ts6.txt#L205-L216
> [2]: https://tools.ietf.org/html/draft-mitchell-irc-capabilities-01
> [3]: =
https://github.com/grawity/irc-docs/blob/master/server/ts-capab.txt
> [4]: https://github.com/grawity/irc-docs/tree/master/client/CAP-drafts
>=20
> --=20
> Joan Touzet | joant@atypical.net | wohali everywhere else