incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [PROPOSAL] Capability identification
Date Fri, 07 Jun 2013 08:28:12 GMT
Big +1


On 5 June 2013 19:36, Jan Lehnardt <jan@apache.org> wrote:

> +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:
> >
> >
>  {"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 | joant@atypical.net | wohali everywhere else
>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message