Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 4 Jun 2013 19:41:42 -0400
From: Joan Touzet <wohali@apache.org>
To: dev@couchdb.apache.org
Subject: Re: [PROPOSAL] Capability identification
Message-ID: <20130604234142.GA17174@atypical.net>
References: <20130604224035.GA31324@atypical.net>
 <CAHdjipLbkKFKgk8DnaM2T3n14hjZ50v94MRFuRy_zOs+cpWSDw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAHdjipLbkKFKgk8DnaM2T3n14hjZ50v94MRFuRy_zOs+cpWSDw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jun 05, 2013 at 03:03:04AM +0400, Alexander Shorin wrote:
> +1
> 
> I'd like also add JIRA issue for reference:
> https://issues.apache.org/jira/browse/COUCHDB-1285

Thanks, I'd missed that one. Looks like the plumbing is on the way
there.

> So your proposal is actually on-half is done. The only missed thing is
> modules (CAPs) info which I believe be more actual after rcouch merge.

There's a bit more to what I've said here. I think it might be useful to
define a (very simple!) process by which the namespace is administered.
Or, at the very least, some guidelines on how to document what
advertising a given module means. In short, it should be possible to
have two totally different implementations of the same functionality,
agree on the CAPAB, but also indicate that they're supplide by different
modules.

I want to avoid the "everyone calls themselves Mozilla in the user-agent
string" problem, but allow a way of saying, for example:  "Yes, I also
provide a view server that speaks JavaScript! No, I'm not actually
couchjs."

-Joan


> --
> ,,,^..^,,,
> 
> 
> On Wed, Jun 5, 2013 at 2:40 AM, 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

-- 
Joan Touzet | joant@atypical.net | wohali everywhere else