httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul A Houle <>
Subject Re: httpd has no reason to improve...
Date Mon, 22 Aug 2005 19:35:04 GMT
Joe Schaefer wrote:

>Paul A Houle <> writes:
>IMO market-share doesn't relate to project activity.  The
>word I most associate with apache development is empowerment;
>cheifly to empower users to build better web stuff.  Users that
>need to tweak the software in order to make that happen become
>committers, who are further empowered to make commits, and eventually
>make decisions about the project as a whole when they join the pmc.
    Market share does matter.  It's a function of a product having a niche.

    A project that's thinking about market share is thinking about end 
users.  A project that isn't thinking about end users is a project of 
people working on something for their own amusement.

>What I personally enjoy seeing on dev@httpd is "piling on", where
>one person implements something, then two or three other people
>(not always committers) jump on the bandwagon and take it in a better
>direction.  It's good to see more of that happening lately.
    Yeah,  soon httpd will have a second- or third-rate implementation 
of every protocol under the sun.

    mod_ftp will underperform mainstream ftp servers so long as its 
running under prefork.  Similarly,  cacheing proxy servers will 
outperform squid.

    I don't see end users clamoring for mod_ftp,  or mod_snmpd.  What's 
the point of writing a squid replacement unless you can actually make 
something better?

>According to the statistics, most users are content with 1.3. But
>that is a very short-sighted way to measure progress, because the
>situation will change as the *nix distros move away from 1.3.  
    And it's got nothing to do with how content users are with 1.3,  but 
with how,  after 54 revisions,  Apache has finally produced a server 
that doesn't have serious problems running in production environments.

>new protocols within httpd will almost certainly will make the internal 
>architecture better, even if none of those modules you mention are 
>distributed with httpd. IMO mod_smtpd will be a fine example of that, 
>because unlike httpd, almost all of the real action will be on the 
>input_filter side (which IMO hasn't received the same amount of polish 
>that the output_filter side has).
    A server framework that can implement any protocol under the sun 
might be a nice PhD thesis,  but what does it do for end users?

    I don't see excellence coming from "swiss army knife" frameworks 
that do everything,  but from systems that are developed from a whole 
system viewpoint,  that have a good amount of codesign between layers of 
the system -- if you build a system that lets you plug in arbitrary 
junk,  you're going to get arbitrary performance and reliability.

    (I think of the old days of Java Applet programming,  where people 
who were just learning OO techniques were writing great complicated 
classes that were trying to be infinitely reusable,  and it took them a 
long time to realize that people were going to have download every byte 
of the class files they were generating...  But it's not just the old 
"bloat" argument,  but the burden of maintaining superfluous code.)

>To sum it up:
>better server architecture => better modules => more toys for users 
>=> more interest in the 2.x internals => more patches => more activity
>=> better server architecture ...
    Sure,  I appreciate mod_ssl and mod_dav in Apache 2 -- but the 
reason why so many people have stuck with 1.3 for so long as that 2.0 
has had very little to offer end users.  A few people thought it would 
be great to have pluggable MPM's,  and a few other people introduced 
half-baked systems such as mod_cache and filters.  You know a tree by 
its fruit,  and the fruit I care about is performance and reliability.  
Apache 2.0.54 is a great server,  but the fact that it took 54 revisions 
to get there isn't a good indication about the design and development 

    Were Apache development targeting real problems that real users 
have,  I think things would be quite different. 

    A big part of the problem is that the Apache project has settled 
into a local equilibrium -- this explains the paradox of a product that 
obviously satisfies end user's needs well (no competition has emerged) 
but has a moribund development process.  Any real innovation in the web 
server space will need to be disruptive,  to break things.  Apache,  as 
we know it,  just can't do that.

View raw message