You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2013/07/17 22:00:23 UTC
[PROPOSAL] Port _db_updates from rcouch to master
Hi all,
I would like to propose (lazy consensus) to port the _db_updates
feature from rcouch to master before the next release.
The code exists in a branch on ASF git (1684-feature-db-updates).
Copying the full commit status:
Import _db_updates from rcouch.
This creates a new top level API endpoint: `/_db_updates`
that returns a line of JSON for each database event along
with the database name.
A database event is one of `created`, `updated`, `deleted`.
The API endpoint supports a `?feed=` parameter with the
options: `longpoll`, `continuous` and `eventsource`.
A second parameter `timeout=` specifies when the server should
close the connection.
`longpoll` closes the connection after a single notification.
It is the default option.
`continuous` keeps a socket open until the specified `timeout`
or 60 seconds by default.
`eventsource` works like continuous, but sends the data in
EventSource format. See
http://dev.w3.org/html5/eventsource/
The parameters are modelled after the existing `/_changes` API
endpoint. Note that `/_db_updates` does not support resuming
of notifications via a sequence ID.
This is a port of the existing DbUpdateNotification interface
to the HTTP API.
Functional changes compared to rcouch:
- make _db_updates an admin-only resource
Docs:
- updated api/misc to include basic info on `/_db_updates`
License:
Apache 2 license, updated LICENSE.
Notice:
(c) 2012 Benoit Chesneau, updated NOTICE.
Tests:
- only manual testing of the various API differences due to
complications with asynchronous HTTP requests in the JS
test suite and total annoyance of overly complicated
ibrowse/httpc modules for writing etap tests.
Recommendation to ship this as EXPERIMENTAL until we have tests.
Cheers
Jan
--
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Jul 22, 2013 at 4:42 PM, Filippo Fadda
<fi...@programmazione.it> 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 (:
--
,,,^..^,,,
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
> 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.
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda
<fi...@programmazione.it> wrote:
> On Jul 22, 2013, at 12:13 PM, Alexander Shorin wrote:
>> Experimental features should be enabled in
>> configs so user takes responsibility for any behavior it provides.
>
> I don't agree because when a feature is not experimental anymore you have to remove it from the "experimental list" and that can introduce new bugs. We are talking about APIs included by default; these APIs are there, but no one is telling you to call them. If you do, the special header field "X-Couch-Experimental" is there to inform that you have called an experimental API, that normally you are not gonna call. It's just a warning, that's all. IMHO.
If uncommenting config options introduces new bugs, so removing him
from experimental list was a mistake, tests are bad and this should be
fixed as soon as possible (:
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.
--
,,,^..^,,,
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
On Jul 22, 2013, at 12:13 PM, Alexander Shorin wrote:
> Experimental features should be enabled in
> configs so user takes responsibility for any behavior it provides.
I don't agree because when a feature is not experimental anymore you have to remove it from the "experimental list" and that can introduce new bugs. We are talking about APIs included by default; these APIs are there, but no one is telling you to call them. If you do, the special header field "X-Couch-Experimental" is there to inform that you have called an experimental API, that normally you are not gonna call. It's just a warning, that's all. IMHO.
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
Experimental in PHP is used for extensions that are not bundled with PHP. Instead deprecated is used to inform the user that a function shouldn't be used anymore. In the same way CouchDB could inform that an API is deprecated or experimental.
1) X-Couch-Deprecated
2) X-Couch-Experimental
Stable makes no sense at all, and unstable too, because an unstable feature should not be included in an official release.
My two cents.
-Filippo
On Jul 22, 2013, at 12:21 PM, Jan Lehnardt wrote:
>
> On Jul 22, 2013, at 12:13 , Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Mon, Jul 22, 2013 at 1:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> We have talked about deprecating features using HTTP headers like
>>> `X-Couch-Deprecated: true` to denote a deprecation to be included in
>>> releases that happen before the actual removal of a feature. We could
>>> make that `X-Couch-API-Stability: [0-5]` instead, if we adopt the scale
>>> above (and maybe only optionally show anything >0 to save some bytes
>>> in the general case). And whatever powers that information could be
>>> used to feed into the capabilities we have talked about for the welcome
>>> message on `/`.
>>
>> X-Couch-API-Stability idea is too complex. Better to have only
>> `X-Couch-Deprecated: true`. Experimental features should be enabled in
>> configs so user takes responsibility for any behavior it provides.
>
> Fair point, happy to have the 1-5 scale in docs only, if we want to
> go that route.
>
>> Also, this information is useless in caps. Caps notifies what server
>> able to do, not how good he can.
>
> Well, if we have comprehensive encoded info on what state everything
> is in, we will also know what we have, which could be used to form
> the capabilities info.
>
> Best
> Jan
> --
>
>
>
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Mon, Jul 22, 2013 at 1:57 PM, Alexander Shorin <kx...@gmail.com> wrote:
> - Big merges: we'll have a lot of "unstable" or not "tested
> extensively in production" API for quite large period of time.
I don't think that's an actual problem. Big merges (that are not
confined to a single or a small set of API endpoints) just shouldn't
be released as experimental.
> - Psyhology: marking something as experimental raises interest from
> hackers and advanced users, regular users will never use these things.
> Unstable badge is not so attractive for hackers, but still regular
> users will try to avoid such API. As the result, API and features will
> not receive good feedback from wide people and this will create
I think that's exactly right. We get something marked as experimental;
hackers and advanced users try it and find bugs, report; if they don't
find bugs anymore, we take away the experimental label, so more people
use it; we can find the rest of the bugs.
Cheers,
Dirkjan
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Jul 22, 2013 at 3:37 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Mon, Jul 22, 2013 at 12:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> X-Couch-API-Stability idea is too complex. Better to have only
>>> `X-Couch-Deprecated: true`. Experimental features should be enabled in
>>> configs so user takes responsibility for any behavior it provides.
>>
>> Fair point, happy to have the 1-5 scale in docs only, if we want to
>> go that route.
>
> I think the docs part is definitely the most important. We should find
> some way to do Sphinx roles for this so we can encode it in a somewhat
> reliable way.
That's not a problem:
:status: stable
+ some styles around (or even own extension to provide custom directives)
The problems are:
- Big merges: we'll have a lot of "unstable" or not "tested
extensively in production" API for quite large period of time.
- Psyhology: marking something as experimental raises interest from
hackers and advanced users, regular users will never use these things.
Unstable badge is not so attractive for hackers, but still regular
users will try to avoid such API. As the result, API and features will
not receive good feedback from wide people and this will create
deadloop: need more feedback to mark feature as stable, need stable
badge to use feature intensively and give a lot of feedback. Time is a
good tester, but it doesn't writes bug reports. Stable looks good, but
ah, still not yet ready for production, let's wait for a while. And so
on.
--
,,,^..^,,,
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Mon, Jul 22, 2013 at 12:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> X-Couch-API-Stability idea is too complex. Better to have only
>> `X-Couch-Deprecated: true`. Experimental features should be enabled in
>> configs so user takes responsibility for any behavior it provides.
>
> Fair point, happy to have the 1-5 scale in docs only, if we want to
> go that route.
I think the docs part is definitely the most important. We should find
some way to do Sphinx roles for this so we can encode it in a somewhat
reliable way.
Also, http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01.
>> Also, this information is useless in caps. Caps notifies what server
>> able to do, not how good he can.
>
> Well, if we have comprehensive encoded info on what state everything
> is in, we will also know what we have, which could be used to form
> the capabilities info.
That might be somewhat useful.
Cheers,
Dirkjan
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 22, 2013, at 12:13 , Alexander Shorin <kx...@gmail.com> wrote:
> On Mon, Jul 22, 2013 at 1:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> We have talked about deprecating features using HTTP headers like
>> `X-Couch-Deprecated: true` to denote a deprecation to be included in
>> releases that happen before the actual removal of a feature. We could
>> make that `X-Couch-API-Stability: [0-5]` instead, if we adopt the scale
>> above (and maybe only optionally show anything >0 to save some bytes
>> in the general case). And whatever powers that information could be
>> used to feed into the capabilities we have talked about for the welcome
>> message on `/`.
>
> X-Couch-API-Stability idea is too complex. Better to have only
> `X-Couch-Deprecated: true`. Experimental features should be enabled in
> configs so user takes responsibility for any behavior it provides.
Fair point, happy to have the 1-5 scale in docs only, if we want to
go that route.
> Also, this information is useless in caps. Caps notifies what server
> able to do, not how good he can.
Well, if we have comprehensive encoded info on what state everything
is in, we will also know what we have, which could be used to form
the capabilities info.
Best
Jan
--
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Jul 22, 2013 at 1:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
> We have talked about deprecating features using HTTP headers like
> `X-Couch-Deprecated: true` to denote a deprecation to be included in
> releases that happen before the actual removal of a feature. We could
> make that `X-Couch-API-Stability: [0-5]` instead, if we adopt the scale
> above (and maybe only optionally show anything >0 to save some bytes
> in the general case). And whatever powers that information could be
> used to feed into the capabilities we have talked about for the welcome
> message on `/`.
X-Couch-API-Stability idea is too complex. Better to have only
`X-Couch-Deprecated: true`. Experimental features should be enabled in
configs so user takes responsibility for any behavior it provides.
Also, this information is useless in caps. Caps notifies what server
able to do, not how good he can.
--
,,,^..^,,,
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
Thx, added the support for this API to ElephantOnCouch.
-Filippo
On Jul 22, 2013, at 8:29 PM, Jan Lehnardt wrote:
>
> On 22.07.2013, at 19:23, Filippo Fadda <fi...@programmazione.it> wrote:
>
>> 2) heartbeat is not expressed in milliseconds like for _changes, but you can pass just true or false. Default is "false" or "true"?
>
> That is my, admittedly ad-hoc interpretation of the code from earlier today. I might have missed something, but it looks like when `heartbeat=true`, _db_updates will send a \n instead of timing out when the timeout limit is hit.
>
> The default is true.
>
> Best,
> Jan
> --
>
>
>>
>> On Jul 22, 2013, at 7:12 PM, Benoit Chesneau wrote:
>>
>>> If it's the same version as in rcouch:
>>>
>>> 1. correct
>>> 2. uncorrect
>>> 3. yes, useless
>>> 4. yes, can't really exists
>>> 5. yes, can't exist we are speaking about deb events
>>> 6. correct, we are speaking about events
>>> 7) yup
>>> others are true
>>>
>>>
>>> On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda <
>>> filippo.fadda@programmazione.it> wrote:
>>>
>>>> HI Jan,
>>>>
>>>> so the differences with _changes are:
>>>>
>>>> 1) there is no "normal" feed, "continuous" is default;
>>>> 2) hearbeat is not supported for "continuous" or "longpoll" feeds;
>>>> 3) feed style option is not supported;
>>>> 4) since option is not supported;
>>>> 5) limit option is not supported;
>>>> 6) descending option is not supported;
>>>> 7) include_docs option is obviously not supported;
>>>> 8) timeout is in seconds instead of milliseconds (?);
>>>> 9) timeout works only for "continuous" feed;
>>>> 10 requires admin privileges.
>>>>
>>>> All right?
>>>>
>>>> -Filippo
>>>>
>>>> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I would like to propose (lazy consensus) to port the _db_updates
>>>>> feature from rcouch to master before the next release.
>>>>>
>>>>> The code exists in a branch on ASF git (1684-feature-db-updates).
>>>>>
>>>>> Copying the full commit status:
>>>>>
>>>>> Import _db_updates from rcouch.
>>>>>
>>>>> This creates a new top level API endpoint: `/_db_updates`
>>>>> that returns a line of JSON for each database event along
>>>>> with the database name.
>>>>>
>>>>> A database event is one of `created`, `updated`, `deleted`.
>>>>>
>>>>> The API endpoint supports a `?feed=` parameter with the
>>>>> options: `longpoll`, `continuous` and `eventsource`.
>>>>>
>>>>> A second parameter `timeout=` specifies when the server should
>>>>> close the connection.
>>>>>
>>>>> `longpoll` closes the connection after a single notification.
>>>>> It is the default option.
>>>>>
>>>>> `continuous` keeps a socket open until the specified `timeout`
>>>>> or 60 seconds by default.
>>>>>
>>>>> `eventsource` works like continuous, but sends the data in
>>>>> EventSource format. See
>>>>> http://dev.w3.org/html5/eventsource/
>>>>>
>>>>>
>>>>> The parameters are modelled after the existing `/_changes` API
>>>>> endpoint. Note that `/_db_updates` does not support resuming
>>>>> of notifications via a sequence ID.
>>>>>
>>>>> This is a port of the existing DbUpdateNotification interface
>>>>> to the HTTP API.
>>>>>
>>>>> Functional changes compared to rcouch:
>>>>>
>>>>> - make _db_updates an admin-only resource
>>>>>
>>>>> Docs:
>>>>>
>>>>> - updated api/misc to include basic info on `/_db_updates`
>>>>>
>>>>> License:
>>>>>
>>>>> Apache 2 license, updated LICENSE.
>>>>>
>>>>> Notice:
>>>>>
>>>>> (c) 2012 Benoit Chesneau, updated NOTICE.
>>>>>
>>>>> Tests:
>>>>>
>>>>> - only manual testing of the various API differences due to
>>>>> complications with asynchronous HTTP requests in the JS
>>>>> test suite and total annoyance of overly complicated
>>>>> ibrowse/httpc modules for writing etap tests.
>>>>>
>>>>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>>>>>
>>>>> Cheers
>>>>> Jan
>>
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Jan Lehnardt <ja...@apache.org>.
On 22.07.2013, at 19:23, Filippo Fadda <fi...@programmazione.it> wrote:
> 2) heartbeat is not expressed in milliseconds like for _changes, but you can pass just true or false. Default is "false" or "true"?
That is my, admittedly ad-hoc interpretation of the code from earlier today. I might have missed something, but it looks like when `heartbeat=true`, _db_updates will send a \n instead of timing out when the timeout limit is hit.
The default is true.
Best,
Jan
--
>
> On Jul 22, 2013, at 7:12 PM, Benoit Chesneau wrote:
>
>> If it's the same version as in rcouch:
>>
>> 1. correct
>> 2. uncorrect
>> 3. yes, useless
>> 4. yes, can't really exists
>> 5. yes, can't exist we are speaking about deb events
>> 6. correct, we are speaking about events
>> 7) yup
>> others are true
>>
>>
>> On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda <
>> filippo.fadda@programmazione.it> wrote:
>>
>>> HI Jan,
>>>
>>> so the differences with _changes are:
>>>
>>> 1) there is no "normal" feed, "continuous" is default;
>>> 2) hearbeat is not supported for "continuous" or "longpoll" feeds;
>>> 3) feed style option is not supported;
>>> 4) since option is not supported;
>>> 5) limit option is not supported;
>>> 6) descending option is not supported;
>>> 7) include_docs option is obviously not supported;
>>> 8) timeout is in seconds instead of milliseconds (?);
>>> 9) timeout works only for "continuous" feed;
>>> 10 requires admin privileges.
>>>
>>> All right?
>>>
>>> -Filippo
>>>
>>> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I would like to propose (lazy consensus) to port the _db_updates
>>>> feature from rcouch to master before the next release.
>>>>
>>>> The code exists in a branch on ASF git (1684-feature-db-updates).
>>>>
>>>> Copying the full commit status:
>>>>
>>>> Import _db_updates from rcouch.
>>>>
>>>> This creates a new top level API endpoint: `/_db_updates`
>>>> that returns a line of JSON for each database event along
>>>> with the database name.
>>>>
>>>> A database event is one of `created`, `updated`, `deleted`.
>>>>
>>>> The API endpoint supports a `?feed=` parameter with the
>>>> options: `longpoll`, `continuous` and `eventsource`.
>>>>
>>>> A second parameter `timeout=` specifies when the server should
>>>> close the connection.
>>>>
>>>> `longpoll` closes the connection after a single notification.
>>>> It is the default option.
>>>>
>>>> `continuous` keeps a socket open until the specified `timeout`
>>>> or 60 seconds by default.
>>>>
>>>> `eventsource` works like continuous, but sends the data in
>>>> EventSource format. See
>>>> http://dev.w3.org/html5/eventsource/
>>>>
>>>>
>>>> The parameters are modelled after the existing `/_changes` API
>>>> endpoint. Note that `/_db_updates` does not support resuming
>>>> of notifications via a sequence ID.
>>>>
>>>> This is a port of the existing DbUpdateNotification interface
>>>> to the HTTP API.
>>>>
>>>> Functional changes compared to rcouch:
>>>>
>>>> - make _db_updates an admin-only resource
>>>>
>>>> Docs:
>>>>
>>>> - updated api/misc to include basic info on `/_db_updates`
>>>>
>>>> License:
>>>>
>>>> Apache 2 license, updated LICENSE.
>>>>
>>>> Notice:
>>>>
>>>> (c) 2012 Benoit Chesneau, updated NOTICE.
>>>>
>>>> Tests:
>>>>
>>>> - only manual testing of the various API differences due to
>>>> complications with asynchronous HTTP requests in the JS
>>>> test suite and total annoyance of overly complicated
>>>> ibrowse/httpc modules for writing etap tests.
>>>>
>>>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>>>>
>>>> Cheers
>>>> Jan
>
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
2) heartbeat is not expressed in milliseconds like for _changes, but you can pass just true or false. Default is "false" or "true"?
On Jul 22, 2013, at 7:12 PM, Benoit Chesneau wrote:
> If it's the same version as in rcouch:
>
> 1. correct
> 2. uncorrect
> 3. yes, useless
> 4. yes, can't really exists
> 5. yes, can't exist we are speaking about deb events
> 6. correct, we are speaking about events
> 7) yup
> others are true
>
>
> On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda <
> filippo.fadda@programmazione.it> wrote:
>
>> HI Jan,
>>
>> so the differences with _changes are:
>>
>> 1) there is no "normal" feed, "continuous" is default;
>> 2) hearbeat is not supported for "continuous" or "longpoll" feeds;
>> 3) feed style option is not supported;
>> 4) since option is not supported;
>> 5) limit option is not supported;
>> 6) descending option is not supported;
>> 7) include_docs option is obviously not supported;
>> 8) timeout is in seconds instead of milliseconds (?);
>> 9) timeout works only for "continuous" feed;
>> 10 requires admin privileges.
>>
>> All right?
>>
>> -Filippo
>>
>> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> I would like to propose (lazy consensus) to port the _db_updates
>>> feature from rcouch to master before the next release.
>>>
>>> The code exists in a branch on ASF git (1684-feature-db-updates).
>>>
>>> Copying the full commit status:
>>>
>>> Import _db_updates from rcouch.
>>>
>>> This creates a new top level API endpoint: `/_db_updates`
>>> that returns a line of JSON for each database event along
>>> with the database name.
>>>
>>> A database event is one of `created`, `updated`, `deleted`.
>>>
>>> The API endpoint supports a `?feed=` parameter with the
>>> options: `longpoll`, `continuous` and `eventsource`.
>>>
>>> A second parameter `timeout=` specifies when the server should
>>> close the connection.
>>>
>>> `longpoll` closes the connection after a single notification.
>>> It is the default option.
>>>
>>> `continuous` keeps a socket open until the specified `timeout`
>>> or 60 seconds by default.
>>>
>>> `eventsource` works like continuous, but sends the data in
>>> EventSource format. See
>>> http://dev.w3.org/html5/eventsource/
>>>
>>>
>>> The parameters are modelled after the existing `/_changes` API
>>> endpoint. Note that `/_db_updates` does not support resuming
>>> of notifications via a sequence ID.
>>>
>>> This is a port of the existing DbUpdateNotification interface
>>> to the HTTP API.
>>>
>>> Functional changes compared to rcouch:
>>>
>>> - make _db_updates an admin-only resource
>>>
>>> Docs:
>>>
>>> - updated api/misc to include basic info on `/_db_updates`
>>>
>>> License:
>>>
>>> Apache 2 license, updated LICENSE.
>>>
>>> Notice:
>>>
>>> (c) 2012 Benoit Chesneau, updated NOTICE.
>>>
>>> Tests:
>>>
>>> - only manual testing of the various API differences due to
>>> complications with asynchronous HTTP requests in the JS
>>> test suite and total annoyance of overly complicated
>>> ibrowse/httpc modules for writing etap tests.
>>>
>>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>>>
>>> Cheers
>>> Jan
>>
>>
Re: Releasing experimental features (was: Re: [PROPOSAL] Port
_db_updates from rcouch to master)
Posted by Benoit Chesneau <bc...@gmail.com>.
If it's the same version as in rcouch:
1. correct
2. uncorrect
3. yes, useless
4. yes, can't really exists
5. yes, can't exist we are speaking about deb events
6. correct, we are speaking about events
7) yup
others are true
On Mon, Jul 22, 2013 at 3:58 PM, Filippo Fadda <
filippo.fadda@programmazione.it> wrote:
> HI Jan,
>
> so the differences with _changes are:
>
> 1) there is no "normal" feed, "continuous" is default;
> 2) hearbeat is not supported for "continuous" or "longpoll" feeds;
> 3) feed style option is not supported;
> 4) since option is not supported;
> 5) limit option is not supported;
> 6) descending option is not supported;
> 7) include_docs option is obviously not supported;
> 8) timeout is in seconds instead of milliseconds (?);
> 9) timeout works only for "continuous" feed;
> 10 requires admin privileges.
>
> All right?
>
> -Filippo
>
> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> > Hi all,
> >
> > I would like to propose (lazy consensus) to port the _db_updates
> > feature from rcouch to master before the next release.
> >
> > The code exists in a branch on ASF git (1684-feature-db-updates).
> >
> > Copying the full commit status:
> >
> > Import _db_updates from rcouch.
> >
> > This creates a new top level API endpoint: `/_db_updates`
> > that returns a line of JSON for each database event along
> > with the database name.
> >
> > A database event is one of `created`, `updated`, `deleted`.
> >
> > The API endpoint supports a `?feed=` parameter with the
> > options: `longpoll`, `continuous` and `eventsource`.
> >
> > A second parameter `timeout=` specifies when the server should
> > close the connection.
> >
> > `longpoll` closes the connection after a single notification.
> > It is the default option.
> >
> > `continuous` keeps a socket open until the specified `timeout`
> > or 60 seconds by default.
> >
> > `eventsource` works like continuous, but sends the data in
> > EventSource format. See
> > http://dev.w3.org/html5/eventsource/
> >
> >
> > The parameters are modelled after the existing `/_changes` API
> > endpoint. Note that `/_db_updates` does not support resuming
> > of notifications via a sequence ID.
> >
> > This is a port of the existing DbUpdateNotification interface
> > to the HTTP API.
> >
> > Functional changes compared to rcouch:
> >
> > - make _db_updates an admin-only resource
> >
> > Docs:
> >
> > - updated api/misc to include basic info on `/_db_updates`
> >
> > License:
> >
> > Apache 2 license, updated LICENSE.
> >
> > Notice:
> >
> > (c) 2012 Benoit Chesneau, updated NOTICE.
> >
> > Tests:
> >
> > - only manual testing of the various API differences due to
> > complications with asynchronous HTTP requests in the JS
> > test suite and total annoyance of overly complicated
> > ibrowse/httpc modules for writing etap tests.
> >
> > Recommendation to ship this as EXPERIMENTAL until we have tests.
> >
> > Cheers
> > Jan
>
>
Re: Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Filippo Fadda <fi...@programmazione.it>.
HI Jan,
so the differences with _changes are:
1) there is no "normal" feed, "continuous" is default;
2) hearbeat is not supported for "continuous" or "longpoll" feeds;
3) feed style option is not supported;
4) since option is not supported;
5) limit option is not supported;
6) descending option is not supported;
7) include_docs option is obviously not supported;
8) timeout is in seconds instead of milliseconds (?);
9) timeout works only for "continuous" feed;
10 requires admin privileges.
All right?
-Filippo
On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Hi all,
>
> I would like to propose (lazy consensus) to port the _db_updates
> feature from rcouch to master before the next release.
>
> The code exists in a branch on ASF git (1684-feature-db-updates).
>
> Copying the full commit status:
>
> Import _db_updates from rcouch.
>
> This creates a new top level API endpoint: `/_db_updates`
> that returns a line of JSON for each database event along
> with the database name.
>
> A database event is one of `created`, `updated`, `deleted`.
>
> The API endpoint supports a `?feed=` parameter with the
> options: `longpoll`, `continuous` and `eventsource`.
>
> A second parameter `timeout=` specifies when the server should
> close the connection.
>
> `longpoll` closes the connection after a single notification.
> It is the default option.
>
> `continuous` keeps a socket open until the specified `timeout`
> or 60 seconds by default.
>
> `eventsource` works like continuous, but sends the data in
> EventSource format. See
> http://dev.w3.org/html5/eventsource/
>
>
> The parameters are modelled after the existing `/_changes` API
> endpoint. Note that `/_db_updates` does not support resuming
> of notifications via a sequence ID.
>
> This is a port of the existing DbUpdateNotification interface
> to the HTTP API.
>
> Functional changes compared to rcouch:
>
> - make _db_updates an admin-only resource
>
> Docs:
>
> - updated api/misc to include basic info on `/_db_updates`
>
> License:
>
> Apache 2 license, updated LICENSE.
>
> Notice:
>
> (c) 2012 Benoit Chesneau, updated NOTICE.
>
> Tests:
>
> - only manual testing of the various API differences due to
> complications with asynchronous HTTP requests in the JS
> test suite and total annoyance of overly complicated
> ibrowse/httpc modules for writing etap tests.
>
> Recommendation to ship this as EXPERIMENTAL until we have tests.
>
> Cheers
> Jan
Releasing experimental features (was: Re: [PROPOSAL] Port _db_updates from rcouch to master)
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 21, 2013, at 10:48 , Noah Slater <ns...@apache.org> wrote:
> Woop! Great to see a merge request. Good to be moving ahead with our new
> workflows.
>
> I'm torn on the testing issue. One the one hand, I think we should stick to
> our guns, and only merge in features with proper tests and docs, and so on.
> (The monthly release cycle should remove any sense of urgency here.)
>
> On the other hand, Jan's proposal seems reasonable. I only worry that if we
> merge the feature now, it may mean that we are waiting longer for the
> tests. (As the pressure to write them goes away.)
>
> Also, this brings up the interesting question of what we do about
> experimental or new features that we want people to test. Do we advertise
> dev builds from feature branches, or do we merge into master and mark as
> experimental? (And does the experimental status of a feature relate to how
> many tests we require at merge time?)
>
> Good questions to address and document for future merge proposals!
>
> I'm not gonna state an opinion either way. I'm sure you folks can figure
> out the best way forward here. :)
Thanks Noah, these are great points we should talk about.
Here’s my thinking. I learned about the notion of EXPERIMENTAL releases
from the PHP community way back when. The skeleton you would build a
new extension from would set the state of the extension to EXPERIMENTAL
by default and it would be custom to remove that, once the author(s) and
the community deemed it ready for production. I don’t recall if there
was ever a formal process for that, but that doesn’t matter here.
The idea of course is avoiding the chicken & egg problem of trying to
ship stable software and only getting bug reports when code is released.
The trick is easy: release the code and mark it, so that at least
*some* people get to run it through its paces and report back errors
that can be fixed to go closer to removing EXPERIMENTAL stage, but not
everybody expects it to run flawlessly.
Then I completely forgot about this in the context of CouchDB. Because
we take stability so seriously, it didn’t occur to me that we could
release EXPERIMENTAL code. This came to a standoff during the CORS
development. We didn’t feel comfortable shipping it, but we didn’t
have any way to get more testing done without shipping this code.
I don’t remember who had the idea, but we ended up shipping CORS as
EXPERIMENTAL and it was exactly the right thing to do and I think this
could be a model for future features.
* * *
The Node.js folks have an interesting addition to this: Instead of
a binary EXPERIMENTAL vs. STABLE bit, they have a 6 point scale from
0. Deprecated
1. EXPERIMENTAL
2. Unstable
3. Stable
4. Frozen
5. Locked
See http://nodejs.org/api/all.html#all_stability_index for the individual
definitions.
I wouldn’t mind adopting this for our API to communicate the state of
certain features and API calls.
We have talked about deprecating features using HTTP headers like
`X-Couch-Deprecated: true` to denote a deprecation to be included in
releases that happen before the actual removal of a feature. We could
make that `X-Couch-API-Stability: [0-5]` instead, if we adopt the scale
above (and maybe only optionally show anything >0 to save some bytes
in the general case). And whatever powers that information could be
used to feed into the capabilities we have talked about for the welcome
message on `/`.
I hope this makes sense :)
What do you think?
Best
Jan
--
>
>
> On 20 July 2013 20:38, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> +1.
>>
>>
>> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> I would like to propose (lazy consensus) to port the _db_updates
>>> feature from rcouch to master before the next release.
>>>
>>> The code exists in a branch on ASF git (1684-feature-db-updates).
>>>
>>> Copying the full commit status:
>>>
>>> Import _db_updates from rcouch.
>>>
>>> This creates a new top level API endpoint: `/_db_updates`
>>> that returns a line of JSON for each database event along
>>> with the database name.
>>>
>>> A database event is one of `created`, `updated`, `deleted`.
>>>
>>> The API endpoint supports a `?feed=` parameter with the
>>> options: `longpoll`, `continuous` and `eventsource`.
>>>
>>> A second parameter `timeout=` specifies when the server should
>>> close the connection.
>>>
>>> `longpoll` closes the connection after a single notification.
>>> It is the default option.
>>>
>>> `continuous` keeps a socket open until the specified `timeout`
>>> or 60 seconds by default.
>>>
>>> `eventsource` works like continuous, but sends the data in
>>> EventSource format. See
>>> http://dev.w3.org/html5/eventsource/
>>>
>>>
>>> The parameters are modelled after the existing `/_changes` API
>>> endpoint. Note that `/_db_updates` does not support resuming
>>> of notifications via a sequence ID.
>>>
>>> This is a port of the existing DbUpdateNotification interface
>>> to the HTTP API.
>>>
>>> Functional changes compared to rcouch:
>>>
>>> - make _db_updates an admin-only resource
>>>
>>> Docs:
>>>
>>> - updated api/misc to include basic info on `/_db_updates`
>>>
>>> License:
>>>
>>> Apache 2 license, updated LICENSE.
>>>
>>> Notice:
>>>
>>> (c) 2012 Benoit Chesneau, updated NOTICE.
>>>
>>> Tests:
>>>
>>> - only manual testing of the various API differences due to
>>> complications with asynchronous HTTP requests in the JS
>>> test suite and total annoyance of overly complicated
>>> ibrowse/httpc modules for writing etap tests.
>>>
>>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>>
>
>
>
> --
> NS
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Noah Slater <ns...@apache.org>.
Woop! Great to see a merge request. Good to be moving ahead with our new
workflows.
I'm torn on the testing issue. One the one hand, I think we should stick to
our guns, and only merge in features with proper tests and docs, and so on.
(The monthly release cycle should remove any sense of urgency here.)
On the other hand, Jan's proposal seems reasonable. I only worry that if we
merge the feature now, it may mean that we are waiting longer for the
tests. (As the pressure to write them goes away.)
Also, this brings up the interesting question of what we do about
experimental or new features that we want people to test. Do we advertise
dev builds from feature branches, or do we merge into master and mark as
experimental? (And does the experimental status of a feature relate to how
many tests we require at merge time?)
Good questions to address and document for future merge proposals!
I'm not gonna state an opinion either way. I'm sure you folks can figure
out the best way forward here. :)
On 20 July 2013 20:38, Benoit Chesneau <bc...@gmail.com> wrote:
> +1.
>
>
> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> > Hi all,
> >
> > I would like to propose (lazy consensus) to port the _db_updates
> > feature from rcouch to master before the next release.
> >
> > The code exists in a branch on ASF git (1684-feature-db-updates).
> >
> > Copying the full commit status:
> >
> > Import _db_updates from rcouch.
> >
> > This creates a new top level API endpoint: `/_db_updates`
> > that returns a line of JSON for each database event along
> > with the database name.
> >
> > A database event is one of `created`, `updated`, `deleted`.
> >
> > The API endpoint supports a `?feed=` parameter with the
> > options: `longpoll`, `continuous` and `eventsource`.
> >
> > A second parameter `timeout=` specifies when the server should
> > close the connection.
> >
> > `longpoll` closes the connection after a single notification.
> > It is the default option.
> >
> > `continuous` keeps a socket open until the specified `timeout`
> > or 60 seconds by default.
> >
> > `eventsource` works like continuous, but sends the data in
> > EventSource format. See
> > http://dev.w3.org/html5/eventsource/
> >
> >
> > The parameters are modelled after the existing `/_changes` API
> > endpoint. Note that `/_db_updates` does not support resuming
> > of notifications via a sequence ID.
> >
> > This is a port of the existing DbUpdateNotification interface
> > to the HTTP API.
> >
> > Functional changes compared to rcouch:
> >
> > - make _db_updates an admin-only resource
> >
> > Docs:
> >
> > - updated api/misc to include basic info on `/_db_updates`
> >
> > License:
> >
> > Apache 2 license, updated LICENSE.
> >
> > Notice:
> >
> > (c) 2012 Benoit Chesneau, updated NOTICE.
> >
> > Tests:
> >
> > - only manual testing of the various API differences due to
> > complications with asynchronous HTTP requests in the JS
> > test suite and total annoyance of overly complicated
> > ibrowse/httpc modules for writing etap tests.
> >
> > Recommendation to ship this as EXPERIMENTAL until we have tests.
> >
> > Cheers
> > Jan
> > --
> >
> >
>
--
NS
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Benoit Chesneau <bc...@gmail.com>.
+1.
On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Hi all,
>
> I would like to propose (lazy consensus) to port the _db_updates
> feature from rcouch to master before the next release.
>
> The code exists in a branch on ASF git (1684-feature-db-updates).
>
> Copying the full commit status:
>
> Import _db_updates from rcouch.
>
> This creates a new top level API endpoint: `/_db_updates`
> that returns a line of JSON for each database event along
> with the database name.
>
> A database event is one of `created`, `updated`, `deleted`.
>
> The API endpoint supports a `?feed=` parameter with the
> options: `longpoll`, `continuous` and `eventsource`.
>
> A second parameter `timeout=` specifies when the server should
> close the connection.
>
> `longpoll` closes the connection after a single notification.
> It is the default option.
>
> `continuous` keeps a socket open until the specified `timeout`
> or 60 seconds by default.
>
> `eventsource` works like continuous, but sends the data in
> EventSource format. See
> http://dev.w3.org/html5/eventsource/
>
>
> The parameters are modelled after the existing `/_changes` API
> endpoint. Note that `/_db_updates` does not support resuming
> of notifications via a sequence ID.
>
> This is a port of the existing DbUpdateNotification interface
> to the HTTP API.
>
> Functional changes compared to rcouch:
>
> - make _db_updates an admin-only resource
>
> Docs:
>
> - updated api/misc to include basic info on `/_db_updates`
>
> License:
>
> Apache 2 license, updated LICENSE.
>
> Notice:
>
> (c) 2012 Benoit Chesneau, updated NOTICE.
>
> Tests:
>
> - only manual testing of the various API differences due to
> complications with asynchronous HTTP requests in the JS
> test suite and total annoyance of overly complicated
> ibrowse/httpc modules for writing etap tests.
>
> Recommendation to ship this as EXPERIMENTAL until we have tests.
>
> Cheers
> Jan
> --
>
>
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 21, 2013, at 10:47 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Sat, Jul 20, 2013 at 9:19 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> I thought marking it as EXPERIMENTAL until there are tests is an ok trade-off
>> about getting this into people’s hands and potentially get a few more bug
>> reports before we call this stable.
>>
>> Dirkjan, do you think this is blocking the merge? If not, I’ll get this into
>> master in time for 1.4.
>
> Sounds good, please merge.
merged, thanks!
Jan
--
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sat, Jul 20, 2013 at 9:19 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I thought marking it as EXPERIMENTAL until there are tests is an ok trade-off
> about getting this into people’s hands and potentially get a few more bug
> reports before we call this stable.
>
> Dirkjan, do you think this is blocking the merge? If not, I’ll get this into
> master in time for 1.4.
Sounds good, please merge.
Cheers,
Dirkjan
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 17, 2013, at 22:37 , Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jul 17, 2013, at 22:22 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
>
>> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> A database event is one of `created`, `updated`, `deleted`.
>>>
>>> The API endpoint supports a `?feed=` parameter with the
>>> options: `longpoll`, `continuous` and `eventsource`.
>>>
>>> A second parameter `timeout=` specifies when the server should
>>> close the connection.
>>>
>>> `longpoll` closes the connection after a single notification.
>>> It is the default option.
>>>
>>> `continuous` keeps a socket open until the specified `timeout`
>>> or 60 seconds by default.
>>>
>>> `eventsource` works like continuous, but sends the data in
>>> EventSource format. See
>>> http://dev.w3.org/html5/eventsource/
>>
>> What about the heartbeat option?
>
> It’s in the code, I must have forgotten to put it into the commit
> and docs.
>
>
>>> - only manual testing of the various API differences due to
>>> complications with asynchronous HTTP requests in the JS
>>> test suite and total annoyance of overly complicated
>>> ibrowse/httpc modules for writing etap tests.
>>>
>>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>>
>> Ugh. I would really like to ship at least one basic test. Is it that hard?
>
> I spent a day and a half to get this sorted and got nowhere. Be my guest :)
I thought marking it as EXPERIMENTAL until there are tests is an ok trade-off
about getting this into people’s hands and potentially get a few more bug
reports before we call this stable.
Dirkjan, do you think this is blocking the merge? If not, I’ll get this into
master in time for 1.4.
Thanks!
Jan
--
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 22, 2013, at 12:02 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, Jul 17, 2013 at 10:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> I spent a day and a half to get this sorted and got nowhere. Be my guest :)
>
> What are we doing to make sure we get tests at some point? Is there an
> issue? Are you or is someone else taking responsibility?
I was betting on peer/user pressure. The code can never lose the
EXPERIMENTAL status without proper tests. I hope we get mocked for
this soon enough :)
Best
Jan
--
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Jul 17, 2013 at 10:37 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I spent a day and a half to get this sorted and got nowhere. Be my guest :)
What are we doing to make sure we get tests at some point? Is there an
issue? Are you or is someone else taking responsibility?
Cheers,
Dirkjan
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 17, 2013, at 22:22 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> A database event is one of `created`, `updated`, `deleted`.
>>
>> The API endpoint supports a `?feed=` parameter with the
>> options: `longpoll`, `continuous` and `eventsource`.
>>
>> A second parameter `timeout=` specifies when the server should
>> close the connection.
>>
>> `longpoll` closes the connection after a single notification.
>> It is the default option.
>>
>> `continuous` keeps a socket open until the specified `timeout`
>> or 60 seconds by default.
>>
>> `eventsource` works like continuous, but sends the data in
>> EventSource format. See
>> http://dev.w3.org/html5/eventsource/
>
> What about the heartbeat option?
It’s in the code, I must have forgotten to put it into the commit
and docs.
>> - only manual testing of the various API differences due to
>> complications with asynchronous HTTP requests in the JS
>> test suite and total annoyance of overly complicated
>> ibrowse/httpc modules for writing etap tests.
>>
>> Recommendation to ship this as EXPERIMENTAL until we have tests.
>
> Ugh. I would really like to ship at least one basic test. Is it that hard?
I spent a day and a half to get this sorted and got nowhere. Be my guest :)
Best
Jan
--
Re: [PROPOSAL] Port _db_updates from rcouch to master
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <ja...@apache.org> wrote:
> A database event is one of `created`, `updated`, `deleted`.
>
> The API endpoint supports a `?feed=` parameter with the
> options: `longpoll`, `continuous` and `eventsource`.
>
> A second parameter `timeout=` specifies when the server should
> close the connection.
>
> `longpoll` closes the connection after a single notification.
> It is the default option.
>
> `continuous` keeps a socket open until the specified `timeout`
> or 60 seconds by default.
>
> `eventsource` works like continuous, but sends the data in
> EventSource format. See
> http://dev.w3.org/html5/eventsource/
What about the heartbeat option?
> - only manual testing of the various API differences due to
> complications with asynchronous HTTP requests in the JS
> test suite and total annoyance of overly complicated
> ibrowse/httpc modules for writing etap tests.
>
> Recommendation to ship this as EXPERIMENTAL until we have tests.
Ugh. I would really like to ship at least one basic test. Is it that hard?
Cheers,
Dirkjan