On Mon, Jul 7, 2014 at 11:44 PM, Russell Branca <[email protected]> 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? https://github.com/apache/couchdb-chttpd/blob/1843-feature-bigcouch/src/chttpd.erl#L601-L607 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: > https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_view.erl#L57. > > Compare these two functions: > > https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_view.erl#L49-L62 > https://github.com/apache/couchdb-couch-mrview/blob/master/src/couch_mrview_http.erl#L191-L204 > > 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: https://github.com/rcouch/couchdb-couch-mrview/commit/4e0f29577c21fb6249fecbfe9f20a46b90f6ae3b 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 rest. 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
