Re: [Libevent-users] http server and infinite streams

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Apr 26, 2011 at 5:26 PM, Mark Ellzey <mthomas@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.