Big +1
On 5 June 2013 19:36, Jan Lehnardt <[email protected]> wrote: > +1, excellent proposal. > > On Jun 5, 2013, at 00:40 , Joan Touzet <[email protected]> wrote: > > > Today, if I GET http://localhost:5984/ , I get: > > > > > > {"couchdb":"Welcome","uuid":"b1b1dbe964914a9cb1467bfd4f297fed","version":"1.3.0","vendor":{"version":"1.3.0","name":"The > > Apache Software Foundation"}} > > > > If I GET from http://mozauto.iriscouch.com/ , I get: > > > > > > {"couchdb":"Welcome","uuid":"bac168113808f7ed357fb53f3a7a68bc","version":"1.3.0","vendor":{"version":"1.3.0r1","name":"Iris > > Couch"}} > > > > And if I GET http://wohali.cloudant.com/ , I get: > > > > {"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1202"} > > > > 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. > > > > [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 > > > > -- > > Joan Touzet | [email protected] | wohali everywhere else > > -- NS
