httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: Apache 2.0 rant
Date Fri, 19 May 2000 01:10:05 GMT
Ryan, don't take this personally.  I think that it's important for you
to get things off your chest whenever you feel like it, but we are
talking about the Apache project right now and not Ryan's code.  It isn't
reasonable to expect that the code is correct just because it has been
in the repository for some time.  The 1.3.x code isn't correct and we've
been working on that for 5 years now.

>For the last month or so, I have seen an increase in the number of
>messages complaining about how Apache 2.0 has been implemented.

Yes, indeed.  I think it has something to do with it being released
as a 2.0 alpha.  The difference is that it officially transitioned
from being a sandbox to a peer-reviewed release candidate.  Think about
that very carefully and you will understand why the code is being
criticized now instead of just viewed as an experiment.

>The funny
>thing is that all of those messages are from people who were very active
>in the 1.3 development, and very inactive in the 2.0 development.

Yes, that too.  That is, after all, what we wanted.  The people with
experience in the 1.3 development are also the ones with the most
experience as programmers, particularly in regard to web server development.

>Different reasons have been given, "I've been to busy", "the
>code is too complex", "I didn't think 2.0 had a future".  I have one
>question for all of those people:  Where were you all two years ago when
>this project started?  Now I'm going to tackle these issues one at a time.

That's a silly question.  They have been too busy to be as active in
the development of a fast moving target to keep up with the work you were
doing on a daily basis.  Is that their fault?  Maybe.  Does that mean
they are any less capable of pointing out poor design decisions and bugs?
Yes, but only a little bit.  What it really means is that they have to ask
a lot of annoying questions just to understand the design, which indicates
that the design is not as transparent as we would like it to be.

>"I've been too busy"  -- too bad, you were too busy doing other things,
>now take the time to learn the new system.  You didn't help write the
>code, and instead of fixing it, you are complaining about it.  That
>doesn't fly with me, I'm ignoring messages from these people from now on.

Nobody can safely fix code that they don't understand.  If they don't
understand it, and you can't point to real documentation that explains it
to a degree appropriate for any professional software developer to
understand, then it isn't their fault.

>"The code is too complex" -- That's right, this code is more complex than
>Apache 1.3.  It is more complex because we aren't trying to support just
>Unix anymore.  If we were trying to support just the platforms that 1.3
>started with, 2.0 would look very much like 1.3, and in a year we would
>have the same unmaintainable code base, because new platforms are being
>added with #ifdefs.  Sorry, this is the price we pay for trying to be
>everything to everybody.

No, it isn't.  The code is too complex because the design does not help
in reducing its complexity.  We are using incomplete types to force
developers to treat the portable data types as abstract, but there is
NO DOCUMENTATION that describes the data types, and the abstraction is
spread over many different header files instead of being constructed as
an ADT.  Don't tell me it is in the API file -- that document only
describes the plan for implementation, not what was actually implemented,
and why, and how it is the programmer is supposed to use APR.  And, no,
it isn't in the .h files either -- the pod documentation only contains
the briefest summary of what each function does, not any of the other
information that is needed in order to treat it as an ADT, let alone
describing the data itself.

These are the same comments that I made when the 2.0 cvs repository was
rebuilt.  The story then was that you and Manoj would get to it when the
code had stabilized to the point where it was worth spending your time on
documentation instead of hacking.  Well, the time has come, either in the
form of writing documentation yourself or simply responding to stupid
questions and the response ending up in the documentation somewhere.

>Now, the other thing that I have noticed, is that people who have been
>working on 2.0 aren't having problems getting code written that is
>usable.  This is not just me, nor is it people who have been working on
>the code consistently since the beginning of 2.0.  Take a look at Jeff
>Trawick, he has come into the picture only in the last two or three
>months, and he commits a lot to 2.0.  Or how about William Rowe?  He
>hasn't been working on 2.0 since the beginning.  Chuck Murcko started
>working on the proxy code for 2.0 in March, he's making good
>progress.  Bill Stoddard is busy, but he still finds time to make commits

Lot's of people have more time to spend on 2.0 than I do.  None of the
people above are running 2.0 on their production servers.  I can't even
make it through a clean compile of 2.0, so I'd hardly call it usable.
Be realistic.  The only way that the code is going to become more usable
is if more people attempt to use it, which means that you are going to
hear a lot more criticism about the existing 2.0 code.  That's why we
are bothering with this whole open source thing.

BTW, clean compile means no valid warnings.

>Bottom line, if you don't like the code, stop complaining and do something
>about it.  Don't tell me the code is too complex for you to understand, if
>that's the case, rip it out and start it over.  When you have something
>working, commit it.  But I am sick and tired of hearing people bitch and
>moan because 2.0 doesn't look like 1.3.

My bottom line is that if you don't WELCOME criticism of the 2.0 code,
both in terms of its design and its implementation, then it isn't
Apache and I will remove it from the repository.  That is the bottom line.
You don't have to change things just because it is criticized, but you
do need to provide enough rationale so that we all understand the parts
of the code that we are trying to fix, or simply tell us to go hog wild
and fix it however we want (and insist that we document our changes).

Feel free to ignore any complaints that don't represent problems that
can be fixed, or for which the complainer has all of the knowledge necessary
to fix for themselves.  But unless you want people to accidentally trash
your design without first asking for a clue, then you shouldn't be
complaining about their level of cluelessness.

So far, every time I have pointed out an area where the code needs some
serious improvement, you have told me to hold off on any changes while
you go do some major rewrite.  That's fine -- I really do appreciate it --
but please realize that I could have done those changes myself, albeit
a lot slower and probably with a few more broken iterations.  If you want
more people to make major contributions, you have to give them a chance
to get dirty as well.

Right now I only have about one day a week that I can reasonably spend
with enough concentrated focus to fix serious problems with Apache.
The rest has to be spent on my real job, my dissertation, the ASF and
Apache Labs, and reading all of the mail that gets generated from all
the fine work of other httpd developers here.  But I can get a hell of a
lot of work done in one focused day, provided I can get the bloody
thing to compile up front.  And besides, that's one more day a week
than I've had for most of the past two years.


View raw message