httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: 3.0 - Introduction
Date Wed, 14 Feb 2007 22:37:42 GMT
On Wed, Feb 14, 2007 at 02:10:19PM -0800, Roy T. Fielding wrote:
> But do we really want to start by calling it 3.0?  How about if we
> work off of a few code names first?  Say, for example, "amsterdam".
> The reason is because there will be some overlap between ideas of
> how to do certain things, with a variety of overlapping breakage
> that can get pretty annoying if you "just want to get one part working
> first".
> I want people to be able to break things in one tree without blocking
> others.  And then, say once a month, we all agree on what parts are
> "finished" enough to merge into all sandbox trees.

I prefer this rather than going straight to 3.0. Would each sandbox
correspond to a single new feature prototype?

> The reason I was about to start the sandbox thing is because I've
> been thinking about moving away from the MPM design.  To be precise,
> I mean that we should get closer to the kernels on the more modern
> platforms and find a way to stay in kernel-land until a valid
> request is received (with load restrictions tested and ipfw applied
> automatically), transform the request into a waka message, and then
> dispatch that request to a process running under a userid that matches
> a prefix on the URI. That's pretty far out, though, and I wouldn't
> want it to stand in the way of any shorter term goals.

This may be too early to jump into design details, but the first thing
that I like about this abstration is a direct mapping between URI-space
and handlers. The second thing that's nice is multi-user support for
any vhost or any portion of a URL path. I don't know how we would pass
a request message containing a large body though. Also, how would this
model gracefully fall back on older syscalls for legacy systems? Would
we simply use a different kernel adapter (kind of like what we have now
with the WinNT and BeOS MPMs)? Really we need to decouple low-level I/O
(disk and network and pipes) from concurrency models (multi-process,
multi-threaded, event-driven async) and also from our protocol handlers.


View raw message