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:20:20 GMT

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

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

I don't think I understand your example, Benoit.

> couchbase-lite can use _bulk_get on the couchbase sync gateway or _changes and other
things on couchdb

Couchbase Lite always uses _changes and other things; those are core parts of the protocol.
_bulk_get is simply an optimization to avoid lots of GET requests for individual documents.
So it makes sense to ask whether the server supports _bulk_get, because the choice is to make
one _bulk_get call or a series of GET /db/doc calls.

> 2 capabilities corresponding to 2 well defined api/protocols. Here why not something
like REPCOUCHDB01 and REPCOUCHBASE01

There aren't two APIs or protocols. There's one, and there are simply some optional capabilities
that can optimize it.

> Describing an expected behaviour is a way easier in my opinion than expecting that all
applications are able to parse a message in time etc.

I don't know what this means.

> why not getting them by issuing an OPTIONS method to / ?

It's apparently not recommended to use OPTIONS (see the mailing list thread.) In RFC2616 the
OPTIONS method is really vaguely defined; it seems it's really only useful for returning Allow:
headers to show what methods are supported. I'd be wary of pushing it any further than that.

> 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