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
needed.
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.
K
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
>
signature.asc
Description: OpenPGP digital signature
