couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: rcouch merge: integration with the bigcouch branch questions
Date Tue, 08 Jul 2014 03:50:37 GMT
On Mon, Jul 7, 2014 at 11:44 PM, Russell Branca <> wrote:
> I switched to using chttpd in couch_mrview for delayed responses as it
> has more robust error handling logic (in particular it fixes a nasty
> bug where error messages were sent as full responses with headers in
> the stream) .
> Benoit, I don't understand what you mean by "Which makes this
> functions unsable with the standalone HTTP api." The change in
> couch_mrview to use chttpd should _not_ prevent the single node
> interface from operating, if you're encountering that then it's a bug.

It was badly phrased. I meant that apparently this change implies now
that I need to use chttpd for the view queries. I just had a quick
glance in the delayed response and not tested it, but doesn't it imply
to handle the request via a chttpd controller?

Looks like it is a special response record. How the view queries are
now working on the couch_httpd api?

> IMO the logical next step for all this is to refactor the separate
> httpd layers into a single app and address the issues there, but I
> think that can wait for 2.x.
> Also, for "port the couch_mrview http modules to chttpd for the layer
> part *and* couch_httpd" I don't think this is the correct approach. I
> think we should define the core http layer in c(ouch_)httpd and then
> continue to use the pattern of the separate applications defining the
> relevant http bits.
> I've already done a lot of legwork to make the http view layer usable
> in both couch_httpd and chttpd with the long term game plan of
> consolidating down to only one http layer. For instance, the clustered
> view logic uses the existing couch_mrview_http code for actually
> sending the responses:
> Compare these two functions:
> You can see they're almost identical, aside from
> `couch_mrview:query_view` vs `fabric:query_view`. I wanted to use the
> view layer as an example of removing unnecessary duplication in the
> two http layers, and to jump start the process of consolidation.
> Hopefully that gives a good idea on approach and the parts that we
> actually need to abstract.

Maybe. I would have done the changes only in chttpd imo since they are
about a new features that won't be ship in 1.7. Especially since I
understand it some wants chttpd and couch_httpd may be merged in a way
or another. Keeping them separated until then would not impact any
future direction about it.

I implemented  the feature using couch_httpd this week-end to support
the feature on the current version:

The relevant part of it, s is that I didn't have to change the
couch_httpd application to support multi queries in view changes for
the _changes handler since this handler was cleanly separated from the

For the 2.0 I think we should consider to completely make the http api
available as a *possible* transport and indeed only have one
application. but until then it worth to keep changes on it separated.
It would ease any work on that part later.

- benoit

View raw message