On 2/14/07, Paul Querna <[EMAIL PROTECTED]> 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.
+1 -garrett
