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
