On Mon, Jul 22, 2013 at 4:42 PM, Filippo Fadda <[email protected]> wrote: > >> I'm in doubt about X-Couch-Experimental header. If for >> X-Couch-Deprecated client library __may__ raise some warning about >> "hey, resource you're requested is deprecated! alarm! alarm!", what >> the reaction should be for X-Couch-Experimental? There couldn't be any >> warnings, because I'm explicitly calls some resource - so I'm aware >> about it existence, know how it works and docs have to aware me about >> experimental status. Otherwise it makes no sense. > > A PHP client library, fox example, could use trigger_error() function to > raise a warning or a notice in case you are calling a deprecated API. I think > the way to react depends by the client implementation, server should just > communicate the fact you are calling an API that is deprecated or > experimental. > > I was thinking that, maybe, the client could use an extra header field to > call the experimental APIs. Instead of notify the client that the API is > experimental, a user could be forced to add an extra header to call the API > itself. This assure the user knows is calling an experimental API. But I see > a problem here: when the API is no more experimental, the user has to remove > that header, changing the application code. >
One more vote for config way to enable experimental features (keeping them disabled by default): config modification requires server administrators privileges, so server explicitly knows what experimental features are enabled on his server and in sure that no users will use them without his permission and/or additional testing. If feature was once enabled in config, there is no need to require additional headers for requests / responses - there should be relaxed way to work with CouchDB, without any additional contracts to use something (even experimental) that should just works (: -- ,,,^..^,,,
