Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Fri, 7 Feb 2014 15:56:29 +0000 (UTC)
From: "Robert Newson (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12693572.1391698766628.5194.1391788589142@arcas>
In-Reply-To: <JIRA.12693572.1391698766628@arcas>
References: <JIRA.12693572.1391698766628@arcas>
Subject: [jira] [Commented] (COUCHDB-2052) Add API for discovering feature
 availability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-2052?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
894656#comment-13894656 ]=20

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

Let's not forget that "discoverability" is already part of CouchDB. The rep=
licator attempts to use optimized endpoints of source and target nodes and,=
 on a 404, falls back to less optimal endpoints, thus gracefully degrading =
for older versions.

There's a lot of abstract talk here and I'm not sure it's helping. Could we=
 take three different examples and then ponder how they would be made disco=
verable? Preferably ones not trivially discoverable by whether they 404.

Some of the ideas above sound extremely cumbersome and more than we need.

> 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)=20
>          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 ag=
reed-upon identifier of a specific optional feature. For example:
> =09{"couchdb": "welcome", "features": ["_bulk_get", "persona"]}, "vendor"=
: =E2=80=A6
> 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 anothe=
r 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 an=
d version thereof it's talking to, and then has to consult hardcoded knowle=
dge that version X of server Y supports feature Z.
> (True, you can often get away without needing to check, by assuming a fea=
ture exists but falling back to standard behavior if you get an error. But =
not all features may be so easy to detect =E2=80=94 the behavior of an unaw=
are server might be to ignore the feature and do the wrong thing, rather th=
an returning an error =E2=80=94 and anyway this adds extra round-trips that=
 slow down the operation.)


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