On Mon, Jul 7, 2014 at 8:50 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Mon, Jul 7, 2014 at 11:44 PM, Russell Branca <chewbra...@apache.org> 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? >
The record is opaque to the view stream callbacks. This just uses chttpd for sending delayed chunks, because it has the better implementation. >> >> 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. > If we cut 1.7 IMO it should be off couchdb master with none of the merge. As far as the merge, it's including chttpd either way. > 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. > I'm a strong proponent for combining the http layers and then drastically decreasing the functionality to only handle the http side of things, and call out to the appropriate application for the database level logic. Believe me, I'm well aware of the overly coupled semantics of the current http stack, both in chttpd and couch_httpd. For instance the default clustering values for db creation are set in chttpd: https://github.com/apache/couchdb-chttpd/blob/master/src/chttpd_db.erl#L201-L216. This obviously is not ideal and most definitely needs to change, but it gets the job done for now. I personally would not block a 2.0 release to wait on a month or two of work to refactor the http layer. It's an optimization for code complexity (albeit a good one), not a feature relevant to people wanting to use BigCouch. > - benoit -Russell
