On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote:
> * Async/Event MPM: Complete Async pipeline for static files. I believe
> we can seriously give every existing single-threaded-event-based server
> a run for their money on every existing benchmark. Toss in some dynamic
> content, and a hybrid Event/Worker has serious potential. Some of this
> work is ongoing in the async-read dev branch, but there is plenty more
> to do.
>
> * A Perchild MPM/replacement: The SoC perchild-replacement project
> didn't work out. We have a basic design that is sound, but we need to
> actually write the code.
>
> * HTTP Removed from the core: I would like to be able to build with
> --disable-http. Sounds crazy, but it will hopefully shrink the core, and
> help us improve other protocol handlers like mod_ftp and mod_smtpd.
Ideas based on prior discussions and personal desires;
* A threaded MPM to become the default: I would like mod_cgid
to die, and for there to be a mod_execd, with an optional ap_exec()
provider. Every place that would have a fork()/exec() can then use
some ap_ function which takes an environment pointer (or NULL for
unchanged), some structure for option suexec stuff, and returns
filehandles for out/in/err. On non-unix/non-threaded it's a noop or
just forks and exec. On threaded, we use a mod_execd (possible with
pre-forking) and pass file descriptors over a local socket.
Weed out other thread-safety nits like the lexx/yacc generated
stuff.
* Configurable buffer sizes; This work is really in apr, and some of
it is done, but buckets need to be tackled next and then it needs to
be hacked in-httpd. But it would be nice to be able to configure the
buffer size used for reading files, both when we read() them and
when we call sendfile() on them, because that's how we get to
scalable TCP flows. Setting "txqueuelen" on an interface isn't much
use without application support for buffering similar ammounts - but
that's what admins are starting to need with the ultra-large
Window-sizes neccessary to get really good flow-performance out of
say a 10G link.
* A small protocol module that lets an admin interface apache via
a unix domain socket. To give the admin an out-of-band channel to
query mod_status when their link is full, or when they've gracefully
stopped.
* Optional XML-ised output for things like mod_status
* Build upon the aaa framework to do some more useful things. Two
in particular I'd like, but they are awkward and contentious.
First, is that we have a lot of third-party providers coming up
with ways of storing state for authentication via http. Most
often via cookies, but sometimes via url-encoded session ID's
and so on. It's messy and ugly, but ignoring the reality of
One-Time Passwords isn't good either, so it might be justifiable
to come with a framework for a united approach. Making say
mod_authnz_secureid only a small bit of work.
The other thing I think is missing from the aaa framework is
a way for an admin to mandate that aaa happen over an encrypted
session only. Some magic directive that doesn't extend into
per-dir/htaccess land that helps them out a little in making
sure that https is being used.
Some of those I have concrete ideas on and plan to code away at, others
are a bit nebulous :)
--
Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
