Paul Querna wrote:
My intention is for this to be a wide open brainstorming thread.
I expect that we will be able to discuss several ideas in much more
detail at the Hackathon next week, but I really want to get all ideas
'on the table'.
I have a few things I would like to see, but I am sure there are perhaps
hundreds of other major features that other people want. It helps to
know what everyone else is thinking about new features, rather than one
person going off an doing it all by themselves. (not that I'll stop
anyone from that either).
Here is my list:
* 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.
I've always wanted to (but not had free time) to write a SEDA-type mpm.
the SEDA is slightly different to the async/event mpm in that a given
hook/filter would process multiple events/requests at the same context
switch. This is what the apr_queue stuff was initially designed for.
I'd also like to brainstorm a better solution to running Rails/Django
applications inside of the httpd process than the SCGI/FastCGI solution
which most people use.
Configuration .. make it configurable. by that I mean allowing people to
use LDAP or a DB to hold the configuration files, and not a flat file.
This is mainly intended for large server farms. Currently the main
reason for logging onto a webserver is to change it's configuration (and
bounce) .. if we could reduce that to just 'bounce' it might make life
easier. (or some method where it checks configs every X minutes and
autobounces..removing the need to log onto the machine at all ;-)
Configuration .. make it easier..I can't think of anything on how to do
this off the top of my head, but it seems to be a common complaint.
Logging/debugging .. changing the log system to use something like Log4C
for errors.. this way the module developer can easily turn on/off
various information on a live system when he is having issues.
wish I could attend the ApacheCon.. if there was a ApacheCon OZ I'd be
there ;-)
regards
Ian
