httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: external config processing
Date Sat, 29 Apr 2000 09:11:13 GMT
[Jim Winstead spoke for me quite well here]

On Fri, Apr 28, 2000 at 02:12:00AM -0700, Greg Stein wrote:
> If we're going to write the code, then why shove it into an completely new
> tool?
> I find it rather silly to write code to support Config Format X, but dump
> that off into a separate tool. The code is going to live somewhere. Why
> shouldn't I place it into Apache itself?

Is it better to write our own tree-parsing code from scratch, or to
just use an XML parser inside Apache and have an external Perl script
convert our config file to XML? (really, I haven't hacked on XML
parsers enough, I don't know)

I don't think we should maintain yet another new config file format,
and a whole new set of tree-parsing routines inside the httpd binary.  

> Code is code. It isn't going to make anything simpler if I have to draw an
> artificial line on where the code should fall. I still have to write and
> maintain the stuff.

This is a very similar discussion to what regularly occurs on the
linux-kernel list. People keep wanting to throw things into the kernel
that can be done just as well outside the kernel.

Keeping stuff outside of the web server binary means that people who
don't need that stuff don't have to use it. If DNS is down; my parser
script dies instead of my web server. If my perl configuration code is
buggy, I'll see it before restarting my web server. And so on.

There is a lot of power in being able to combine lots of little tools
using ASCII interfaces to do amazing things. OO before OO was cool. :)

> Yah. Right. Until the path gets screwed up. Or when somebody goes to chown
> Apache for some purpose, but misses this external tool.

There are 40,000 ways for this to happen now. Oops, the user's home
directory has 0700 permissions, or the conf files aren't readable by
user httpd. 

> Making something external, yet the same under the covers, simply argues to
> truly making it the same chunk of code.

To use more exagerrated examples, applying this statement would mean
that the window manager should be integrated into the X server. The
shell should be integrated into /bin/login. All of GNOME or KDE should
be one big fat binary.

View raw message