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