httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject 3.0 - Proposed Goals
Date Wed, 14 Feb 2007 07:33:27 GMT
So, I've been kicking around some ideas about where I personally would
like trunk to go for a couple months now.

My personal goals for 3.0:
 - Write some cool stuff, that is fun to hack on.
 - Create an environment that encourages others to contribute, A project
this large cannot and should not be done alone or by a small group. Part
of this means my goal is to meet whatever the personal goals are with
others for httpd; Others might not want cool stuff, or fun stuff, or
they might want something else.

More Product-type Goals:

- Rewrite the Core to be an Async Event state machine and data router.
The core should only route events to protocol modules.  All it handles
is the state machine of connection A is waiting for input, Connection B
is waiting for Disk IO, connection C is being run by another thread,
etc..  This could lead to things like mod_proxy being able to run
completely asynchronously, eliminating many performance issues we see

- Rewrite how Brigades, Buckets and filters work.  Possibly replace them
with other models. I haven't been able to personally consolidate my
thoughts on how to 'fix' filters, but I am sure we can plenty of long
threads about it :-)

- Break the 1:1 mapping of a worker to a single request.  In trunk (and
2.2) with the Event MPM, we have broken the 1:1 mapping of a single
thread to a connection, the next step is to break up a request into a
series of state changes, which would contain attributes stating if they
require a blocking operation. If any operation could block, we would
assign a worker to handle it (or perhaps use the leader model). Linux
also has some interesting ideas going with Syslets to execute system
calls in an async manner. and this is something I would like to
experiment with:

- Change the meaning of MPMs. The problem with MPMs today is they are
really mostly platform abstractions -- not just abstractions of the
process model itself.  For example, if the Worker MPM was ported to use
the correct windows functions, there is no real reason it could not
replace the winnt MPM.  I believe we should try to move platform
abstractions back into APR or other util functions, and try to have a
single MPM that runs on all multi-threaded platforms.

- Include support for Waka. Roy has less than 1 year to get us an RFC :-)

- Build a cleaner configuration system, enabling runtime
reconfiguration. Today's system basically requires a complete restart of
everything to change configurations.  I would like to move to an
internal DOM like representation of the configuration, but preserve the
current file format as the 'default'. (Modules could easily write an XML
config file format, or pull from LDAP).

- Experiment with embedding scripting languages or something like
Varnish'es VCL if and where it makes sense. (Cache Rules, Rewrite Rules,
Require Rules, and the like).

- Experiment with the right way to abstract state machines,
multi-threading, and async IO from module developers who want a 'simple
world view'.  Most modules just want to run a few hooks, or generate
content.  We should preferably easier to do this than it is today.

- Find a better release model for a 3.0/trunk.  I don't think many
people are happy with how 2.0.x was handled in this respect, but I do
believe we need to release early and often.

- Promote and include a external-process communication method in the
core.  This could be used to communicate with PHP, a JVM, Ruby or many
other things that do not wish to be run inside a highly-threaded and
async core.  The place for large dynamic languages is not in the core
'data router' process. Choices include AJP, FastCGI, or just HTTP.  We
should optionally include a process management framework, to spawn these
as needed, to make configuration for server administrators easier.

- <insert your ideas here>


View raw message