couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
Date Fri, 07 Feb 2014 16:52:20 GMT


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

View raw message