couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [PROPOSAL] Port _db_updates from rcouch to master
Date Sun, 21 Jul 2013 08:48:41 GMT
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 <bchesneau@gmail.com> wrote:

> +1.
>
>
> On Wed, Jul 17, 2013 at 10:00 PM, Jan Lehnardt <jan@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message