On Tue, Apr 26, 2011 at 5:26 PM, Mark Ellzey <mtho...@strcpy.net> wrote: [...] > While I support these types of changes, I often wonder if the better > solution to these problems is to gut the httpd API and create a more robust > and abstracted replacement. *prepares for flogging* > > Libevent's http API was created for JIT services, not a apache/nginx/iis > replacement. But the reality is, developers have shown that the system should > be just as robust as the real ones. > > A project to keep an eye on (one I have started using after dealing with > the many faults of the libevent http engine) is > https://github.com/ry/http-parser
Cliff Frey then wrote: > However, if we are worried about the actual HTTP parsing of > libevent/http.c, I could likely rip it out and replace it with > https://github.com/ry/http-parser, but again, I'd love to know if such > a change would actually be accepted or not beforehand... I would totally support an effort to replace the internals of evhttp.c with something better and more maintainable in a future version of Libevent: the current code is indeed pretty crufty. My only personal show-stopper issues for dropping it in as an evhttp replacement would be: a) No making the license stricter. (IOW, if it's GPL, that's great, but it can't go in Libevent proper.) b) No breaking existing programs that use the current APIs correctly. People should be able to write correct code on Libevent 2.0.11-stable that works on future versions of Libevent for a very long time; they shouldn't be setting themselves up for an arbitrarily big maintenance process. I think this is doable, though: the current API could stand to be revised, but it seems like something that a good replacement implementation could sure emulate. c) No removing functionality. This follows from the last point. d) Everything really does need to be tested as much as possible. Fortunately, the unit test coverage for http.c isn't so bad; there's almost 80% test coverage right now. The higher we can get that, the more confident we could be Or to be briefer: "I am not at all wedded to the current evhttp implementation, and I am okay with deprecating bad parts of the current API. In fact, I'd welcome improvements to both, so long as they are well tested, well designed, and don't break backward code compatibility." peace, -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
