Dumb Question: Would all this mean a total(?) rewrite of APR as well?
-- dims On 2/14/07, Aaron Bannert <[EMAIL PROTECTED]> wrote:
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. -aaron
-- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
