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 separating platforms by directory
Date Tue, 16 May 2000 01:12:48 GMT
>Roy, I know there are people who dislike the directory structure.  Here's
>a question for you.  How often have you tried to fix a bug in APR?

Six times, not counting the license changes.  Two resulted in commits and
the other four were abandoned because the entry barrier was too high
(by the time I figured out the five different places that I would have
to change code before it could be reasonably tested, my scheduler
swapped my mind for another task).  That's not a very good ratio, since
I'm one of those annoying people who always tries to finish what he starts.
My ratio for other parts of Apache is about 4/6, and those problems are a
lot bigger.  Lately, I just assume it will take too long and ignore APR
problems until I have a complete day free [any year soon].

I don't think that there is an easy solution to any of this, but the
current one is not working for me. I would rather not propagate it further.
I suspect it is one of the reasons why so few people work on APR.
I haven't said anything about it because I still feel that the people
doing the most work in that area should have first choice as to how
the thing should be organized.  It may be just a matter of personal
style and the process I go through in solving problems.

I have the same complaint regarding the location of MPM stuff. It is
now a serious pain in the ass to work on a problem in the core because
you need to jump all over the directory system just to follow the
request handling process.  Likewise, much of that code is duplication
just for the sake of having different sandbox areas, or just because
somebody never got around to cleaning up their own experiments.

>Have
>you noticed that most of the code that is in different directories doesn't
>look anything alike?  We have solved this issue by having common code be
>truly common.  The code that isn't common is in different
>directories.  This means that there shouldn't be much, if any, code
>cut-and-pasted from one directory to the next.  Take a look at the BeOS
>file_io code.  It's non-existant, because all of that code was an exact
>copy of the Unix code.  Or, take a look at the time functions.  There are
>only two directories, unix and win32, but the code works on beos and os/2
>because they automagically use the unix code.

Dude, I just randomly picked two files from apr and did a comparison.
For socket.c, about 60% of the code is common on all platforms, and another
20% only appears to be different because they have diverged in the
use of whitespace, variable names, and in the application of bug fixes.
For threadcancel.c, 80% of the code is common cut-and-paste.  Look at the
output of something like

   cd lib/abr
   find . -printf "%f\t\t%p\n" | sed '/CVS/d' | sort

and tell me that this is a rational way to maintain code.  Worse yet,
do the same for the modules/mpm directory.  And please don't tell me
that the differences between 

   diff -u unix/sockets.c beos/

are due to platform differences -- they aren't.  Half are missing
bugfixes and the rest are mostly functional differences where one
platform isn't providing the same functionality as the other.
That is a symptom of unmaintainable code.

I don't care whether it looks alike or not -- if it is supposed to
be doing the same thing, it should be located in the same place.  If two
different platforms do the same thing in differing ways, I want the
comments in the code to explain why they are doing it differently.
We should learn from the differences, not segregate them.  Placing
the differences in separate files makes sense if they are entirely
different, but I have yet to encounter a reason to put them in separate
directories.

>If there is a real issue here, then lets fix it, but #ifdefs don't help
>when the entire function is five big #ifdefs, it just makes the code
>harder to read and understand.

The only place I need ifdefs is in macro declarations.  Conditional code
becomes unreadable when people use individual characteristic tests
(like #ifdef EWOULDBLOCK) instead of extrapolating all of the possible
conditions into a functional test (like ap_would_block(errno)).
This applies within APR for the same reason that clients of APR want
to use APR as an abstraction library.

WHAT TO DO?  Not a thing, at least not until I get enough time together
to actually do the real work of re-merging all of the common code and
abstracting away the true differences between platforms.  And that isn't
going to happen this year.  I just got tired of watching the code
dissipate into unmaintained islands without at least saying something.
Consider it a request for Apache 3.0.

....Roy

Mime
View raw message