couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus Trainer <>
Subject Re: Server feature detection
Date Thu, 06 Feb 2014 01:22:23 GMT
I believe that trying to make the relevant information available via the
"/" handler is moot, as there already is a configuration handler, which
should probably be used instead.  The configuration handler is available
on the "/_config" endpoint and gives you quite a lot of information.

CouchDB is becoming increasingly modular and currently is being split up
into multiple stand-alone (OTP) applications that may or may not run in
the same VM.  However, CouchDB actually has a pretty pluggable
architecture already, and there is basically is no "hardcode knowledge
that version X of server Y supports feature Z", as not only the
configuration of components, but whole components themselves can be
plugged in, upgraded, or removed during runtime without a restart being

Regarding your example about trying to find out if a _bulk_get feature
is available, this is what you could do: check if the
"httpd_db_handlers" object has a "_bulk_get" property.  If yes, it means
that there is a handler for "/:db/_bulk_get" queries.

Thinking more about that, it would be cool to however have the
possibility to make additional meta-information available in the
configuration handler JSON, which I believe is currently not the case.


On 02/05/2014 09:22 PM, Jens Alfke wrote:
> Features are being added to CouchDB over time, and there are compatible servers that
may have nonstandard features (like _bulk_get). But there isn't a clear way for a client (which
might be another server's replicator) to determine what features a server has. Currently a
client looking at the response of a GET / has to read tea leaves to figure out what server
it's talking to, then based on that parse the version number, and then has to consult hardcode
knowledge that version X of server Y supports feature Z.
> (True, you can often get away without needing to check, by assuming a feature exists
but falling back to standard behavior if you get an error. But not all features may be so
easy to detect — the behavior of an unaware server might be to ignore the feature and do
the wrong thing, rather than returning an error — and anyway this adds extra round-trips
that slow down the operation.)
> As for version detection, here's what I get from CouchDB:
> 	{"couchdb":"Welcome","uuid":"9c0667e0ec68a712ccf99a2eb84fd299","version":"1.4.0",
> 	"vendor":{"version":"1.4.0","name":"The Apache Software Foundation"}}
> Cloudant:
> 	{"couchdb":"Welcome","version":"1.0.2","cloudant_build":"1866"}
> Couchbase Sync Gateway:
> 	{"couchdb": "welcome", "version": "Couchbase Sync Gateway/0.93"}
> IrisCouch:
> 	{"couchdb":"Welcome","uuid":"270c0130ca0e1d8e54fc48be8aaa7d6a","version":"1.3.0",
> 	"vendor":{"version":"1.3.0r1","name":"Iris Couch"}}
> I hadn't noticed the "vendor" property before; probably it was added to CouchDB after
I'd implemented my first "/" handler :) I'll add that to the next release of the Sync Gateway.
That takes care of deducing the server and version.
> But it would still be best to explicitly encode information about features. How about
adding a property called "features" or "extensions" whose value is an array of strings, each
string being an agreed-upon identifier of a specific feature? For example:
> 	{"couchdb": "welcome", "features": ["_bulk_get", "channels"]}, "vendor": …
> —Jens

View raw message