httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: 3.0 - Proposed Goals
Date Wed, 14 Feb 2007 20:28:06 GMT
Paul Querna wrote:
> 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.

It's always been small groups ;-)  But we are loathe to drop the 'barrier
to entry' of demonstrating that the new coder is 'cluefull'.  This is a
server platform, rife with the security issues that go along with that.

But I have no issue with us identifying new committers who successfully
and consistently add worthwhile code.  Propose them to private@.

See proxy-dev, the netware guts, the win32 guts, even rewrite or ssl
for some code that very few understand but makes for a bigger whole.

> 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
> today.


-1 to requiring an async model OS/communications stack.

You might think you are doing everyone a huge favor by setting a high
bar, but you neglect all the micro OS / embedded places that apache
can live today.  You might get a kick out of the March 07 Dr Dobbs
on this topic.

> - 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 :-)

+1 - let's start with serf.  Right now we have a pretty big stack space
burden, something that sucks for thousands of parallel threads.  Let's
eliminate that stack nightmare and pass brigades sideways, not down the
stack, and remove the input/output distinctions.  Also, let's get the
metadata right this time :)

> - 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:

Fun technologies.  Fix brigade passing and you can accomplish whatever
you would like.  Provided that brigade passing and filtering can be
"incomplete" and we solve that issue, then everything else you want to
do can fall into the MPM pattern.

> - 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.

Ok I'm confused.  First, worker requires fork, that isn't likely to
change, some platforms don't fork, so we will always have forking and
non-forking models.  A better question/example is why Netware and Win
don't share one, overall more effective MPM.

+1 to few, well identified MPM's, to do the traditional request queue
or the event model.  And the real test, the truly async MPM (third party
module users beware ;-)

-1 to even suggesting we change what they are.

+1 to making them loadable ;-)

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

Ha.  Seriously you missed one, let users drop mod_http.  If they want to
run with only mod_waka, or mod_ftp, or mod_pop3+mod_snmp that's their
choice.  Loadable mod_http is the start of that.

The second aspect gets tricky; resource abstraction in a protocol neutral

> - 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).

We are getting closer since 2.0.0, +1.  Offer the appropriate abstract
containers for folks to play mod_perl'ish games.

> - 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).

You'll get alot of -1's to this as a part of the core. As a module - cool.

> - 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.

Take it to apr.

> - 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.

2.0.x howso?  We won't improve it if you don't elaborate what you didn't
like.  If you refer back to the constantly broken state of releases
prior to, oh, say 2.0.36 or so, then we already have it solved.  Start
releasing 2.9.0 releases unstable and let's let people play.  But 2.1.x
showed that not enough of them do, maybe this is more of an 'advertising'
sort of problem.

> - 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.

???  Ok, you confused me here ;-)  You want to reinvent the System.Web.Host

View raw message