You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Robert Newson (JIRA)" <ji...@apache.org> on 2014/02/06 16:06:12 UTC

[jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability

    [ https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13893418#comment-13893418 ] 

Robert Newson commented on COUCHDB-2052:
----------------------------------------

+1. We have talked about this but haven't acted. It would be useful to get rid of the single version number while we're at it. It's difficult to convey the compatibility of CouchDB with Cloudant with PouchDB etc through a single value.


> Add API for discovering feature availability
> --------------------------------------------
>
>                 Key: COUCHDB-2052
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2052
>             Project: CouchDB
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: HTTP Interface
>            Reporter: Jens Alfke
>
> I propose adding to the response of "GET /" a property called "features" or "extensions" whose value is an array of strings, each string being an agreed-upon identifier of a specific optional feature. For example:
> 	{"couchdb": "welcome", "features": ["_bulk_get", "persona"]}, "vendor": …
> Rationale:
> Features are being added to CouchDB over time, plug-ins may add features, 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 figure out what server and version thereof it's talking to, and then has to consult hardcoded 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.)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)