On 05. Februar 2014 at 21:23:10, Jens Alfke ([email protected]) 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

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

Reply via email to