couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Server feature detection
Date Wed, 05 Feb 2014 23:07:52 GMT
On 05. Februar 2014 at 21:23:10, 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
> 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
> — the behavior of an unaware server might be to ignore the feature and do the wrong
> 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
> 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

Hi Jens,

Feature detection was one of the future suggestions for the vendor field, not just around
replication of course, but from an interop perspective that’s one of the most interesting. 

Do you think there’s a need to have versions attached to the features? Would this work for
plugins as well?

This would be a prime candidate for a JIRA ticket as well.

Dave Cottlehuber
Sent from my PDP11

View raw message