Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 15 May 2000 20:49:24 -0400 (EDT)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: separating platforms by directory
In-Reply-To: <200005151812.aa09502@gremlin-relay.ics.uci.edu>
Message-ID: <Pine.LNX.4.21.0005152034001.1618-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> 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 don't think the problem is the design, but rather the implementation.  I
will take tomorrow and try to combine common code in APR.  This has been
sorely needed for a LONG time, and I keep putting it off because it is an
annoying problem.  I don't want to just combine all of the code, because
for the most part the Windows and OS/2 code is not just copied-and-pasted
from Unix (if there are sections that are, I'll find them
tomorrow).  Please, after I finish, look again and tell me if more needs
to be done to make this easy for people to join in.  Your feeling that
people aren't contributing because of this is something I have been
worrying about, so I guess now it's time to fix it.

> 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.

Again, this may take time to fix, but it will get done, because I too am
sick of fixing the same problem in multiple places.  I expect to spend
most of this week find and combining common 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

Okay, then those are two files that shouldn't have been implemented the
way they were.  Most of the BeOS code should probably be using Unix code
now.  But, nobody has been doing the BeOS work because David has been away
for a while.  Try looking at open.c in unix and win32.  Those are the
kinds of differences I want to keep separate.

>    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.

No, they aren't due to platform differences.  They are due to having
separate code for platforms that shouldn't be separate.

> 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.

So in file_io.c, you want open_unix.c open_win32.c filestat_unix.c
filestat_win32.c, etc.  These are separated because we don't use POSIX
function calls on Win32.  They are separated in directories because they
are wildly different, and they don't share any common code, this makes it
easier for some of us to find and fix bugs, because I don't have to try to
fix Windows bugs that aren't there, because Windows has handled a case
that POSIX didn't.

> 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.

If I understand what you are saying, then I agree for the most part.  I
want as much common code to be common code as possible.  I just also want
to keep the code that is entirely different (like OS/2|Unix|Windows) code
to not get in people's way.  Do me a favor, I'll post when I've combined a
lot of common code, and ask people to look at it again, when I do that,
take another look and tell me if I have come close to what you would like
to see.  Expect me to muck around with APR first, and the MPMs second.

I will be dedicating the next week to week and a half to major cleanups,
instead of adding features or fixing bugs.  The more people who can work
on the code, the better off this project is.  If the mess that is 2.0 is
hampering people from working on the code (which is the general impression
I am getting from a couple of different people), then we need to fix it.

> 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.

Consider your request heard and listened to, because we need to keep this
code something that other people can work on.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------