couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Alfke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
Date Fri, 07 Feb 2014 15:48:19 GMT

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

Jens Alfke commented on COUCHDB-2052:
-------------------------------------

This discussion is starting to smell like bike-shedding to me (and it's not the first time
that's happened with CouchDB.) 

I raised a fairly straightforward issue -- given different versions and implementations that
might not all support the same functionality, how does a client know whether or not it can
use a particular feature/function? -- and proposed a straightforward solution.

My solution might not be perfect, but it's clearly specified and very easy to implement and
to use. The responses here seem to be digressing, and no one is proposing anything concrete.
The other ideas here also sound like they'd be significantly more complex.

Basically, if someone else has an alternative proposal for how to do this, then specify it
clearly and post it here.

> 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)

Mime
View raw message