Re: rewrite of NCSA httpd ?

Rob McCool (robm@neon.mcom.com)
Sun, 2 Oct 1994 20:03:16 +0100

/*
* "Re: rewrite of NCSA httpd ?" by Simon E Spero <ses@tipper.oit.unc.edu>
* written Sun, 2 Oct 1994 17:56:36 +0100
*
* On Sun, 2 Oct 1994, Richard Huddleston wrote:
** I've just spent the past six weeks wading through the biggest
** collection of spaghetti code I've ever seen in my life: the NCSA
** httpd.
*
* There's no need to take such a hostile tone in a public forum;
* although the NCSA code has many problems relating to performance, I
* found the code quite simple to understand. Remember that when this
* code was written, Rob was also a full time student. In those
* circumstances, the most important dimension to optimise for is
* time-to-implement- it's more important to make something work than
* to make it look pretty. Considering the amount of evolutionary
* changes that took place in HTTP, and all that interference from
* those Browser Weenies, the code is remarkably clear.

I think the code also demonstrates why things that look simple aren't
always good. As Roy points out, by last Spring I had found that the
whole thing had evolved through the factors Simon describes into
something unmanagable and I was about to re-architect the whole thing
when I got a little sidetracked... now I have a nice pile of managable
code but sorry, you can't read it :)

I'm now condemned to watch every few weeks as someone else figures out
that internally, NCSA httpd isn't the pinnacle of modern computer
science they'd hoped it to be and they jump to flap their yap on
www-talk about it. You aren't the first, Richard; at times, I've seen
fragments of my code held up to scare little children. Some people
would mail httpd@ncsa.uiuc.edu about it first, which was good, and I
would always try to calm them down and then help them out. Most of
them don't mean to be harsh, and temporarily forget that it's best not
to trivialize the efforts of people they may need help from, but
they've been frustrated while trying to get feature X to work (or
poring over the code and trying to add feature Y, or ...) and that's
reflected in their messages.

* If you want to see real pasta programming, take a look at the WAIS
* source code (only some of which I'm responsible for).
*/

I can top that one. I once worked on a project which was over 25,000
lines of 65816 assembly code, which is 16-bit. The code was originally
written by Japanese programmers for the 32-bit 68000, and ported by a
person who was very enthusiastic, but was also very new to the whole
assembly scene and (to be polite) wasn't very good at it yet.

If there were ever any comments, they weren't likely to make any
sense. The original authors named modules in Japanese, with the
author's initial before the module name, so modules ended up being
called things like kbutai and ktensiset. Inside each module, there
were usually 20-30 subroutines, all of which did something subtly
different and often jumped into each other, all of which were named by
number, as in kbutai00 - kbutai19. Being assembly language, there were
a lot of branches and jumps within these functions which went to
labels that were parts of nested loops. Some of these loops were over
ten pages long. These labels would again not be named, but numbered.

*That* was a hearty plate of spaghetti. Weighing in at a little over
6,000 lines of C, I think NCSA httpd was more like Mac and Cheese.

--Rob