[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894716#comment-13894716
]
Benoit Chesneau commented on COUCHDB-2052:
------------------------------------------
[~snej] sorry I didn't have any crystal ball around me when I was posting my
answer ;)
1. is already solved by my method. provides the link template and you will have
it. Eventually the type. Also we can eventually enhance it...
But if you have an uri /{db}/_changes?feed={websocket} it works.
2. The HTTP spec expect that your sending the right header to tell to the
server you want a specific content-type or encoding. And should be handled by
the server. If not it's a bug. Saying you're accepting gzip and reading the
content-encoding sent by the server solve ost of the cases. Not sure what it is
not fixed by doing this....
3. it's fixed now. This was a bug imo, and I don't think that it should be
advertised (neither it could have been). It was discovered because some people
like you started to use this api. It wasn't an issue when the only client for
it was the couchdb replicator. Imo this is also fixed by the solution I've
given. If you know the server and the version then you know the bugs in.
I do think that the simple solution already solved a lot of case but I am not
sure that the one you proposed was handling all the problem you mentioned
above. Or I am confused, where a client would know what "persona" means?
> 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)
