Paul A Houle wrote:
Ben Collins-Sussman wrote:

I see a lot of frustration going on. The thing is, httpd's development process is nearly identical to Subversion's process... we stole most of it from you folks! So why all the angst in httpd-land, but not in Subversion-land?

Too many versions.  And conflicting views on how to deal with them.

   It's really a lack of direction.

Lack of what?

Support for major up-and-coming technologies like LDAP?
A working cacheing framework?
The biggest improvement in database management since mod_perl
pioneered the LAMP architecture ten years ago?
Untying authentication protocols from provider implementations?

I could go on, but those seem like worthwhile directions.
All happening because people want them.

There is very little going on in Apache to make it be a better web server

Nonsense.

 -- the frontiers of development are trying to make it an ftp
server, an smtp server, a ntp server, a snpd server, a bgp

Erm, I know we're doing SMTP: that's to harness the input filter chain
for spam filtering.  FTP has been around for some time.  Where are all
those other protocols?

The module mechanism means that significant improvements in Apache can be made without making changes to the Apache distribution -- people are who are serious about improving Apache as a web server are taking this route and not adding things to the Apache distribution. (Any

Indeed, we can do a lot with modules.  A number of us who are now core
developers started out as application developers writing modules.  The
more modules you write, the more you see how the core product can be
improved, the more you contribute.  Well, that's (broadly speaking) how
I came to Apache, and I'm not the only one.

Before 2.0 - specifically filters - Apache didn't cut it for
applications.  The payback for writing modules (as opposed to
apps running under CGI, mod_perl, etc) wasn't worth the effort
from my PoV.

People who want to wake Apache up would be best to try a fork. Throw things that are irrelevant to running httpd on Posix overboard. Pick ONE mpm that offers a significant advance in functionality (mod_event or mod_perchild that actually works) and qualify everything to run against it. Add mod_macro.

Feel free to do exactly that.  I don't find it a problem to write
modules that work across platforms and MPMs, and I value the fact that
modules work cross-platform without hair-tearing (and with less trouble
and overhead than many cross-platform environments like Java).

But why? Apache is good enough for most people, and you can fix any real problems for a particular project by adding modules or making little source code patches. There are 1,000 or so sites in the world that need an MPM faster than prefork, and they'd be better off going to a cluster strategy for availability anyway.

What's "faster than" got to do with it?  You want a justification for
threaded MPMs, just look at connection pooling apps, and the first
big advance in scalability since LAMP.

Apache 2 was a rough ride, but Apache 2.0.54 runs smooth on every installation I have... Why change anything?

I hope you don't run those new-fangled gadgets like a mouse?

--
Nick Kew

Reply via email to