httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <>
Subject Re: 3.0 - Proposed Goals
Date Wed, 14 Feb 2007 13:45:49 GMT
On 2/14/07, Paul Querna <> wrote:

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

I think a big part of this should be documenting how filters are
supposed to interact with the rest of the system.  Right now it seems
to be very much a "well, I looked at this other module and did what it
did", and it's quite easy to start depending on behavior in the system
that isn't actually documented to work that way.

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

This seems like a rather invasive change.  Virtually every module
currently caches configuration info into global variables.  Are we
expecting these modules to dynamically query the core config system
whenever they want to access this sort of information?  What will the
performance implications of this sort of thing be?

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

This seems like a Good Idea (tm).

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



View raw message