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 <[email protected]> wrote: > +1. > > > On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <[email protected]> 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
