Re: external config processing

[Greg Stein <gs...@lyra.org>]

On Wed, 26 Apr 2000, Jim Winstead wrote:
> On Apr 26, Greg Stein wrote:
> > IMO, I think it is better to "include the batteries" rather than saying
> > "we won't do that -- use an external script." If that were the case, then
> > we should rip out everything under modules/ and tell people "go get the
> > stuff you need; it does not come standard with Apache."
> > 
> > People want to install and run. External processors and config
> > manipulators simply make that more difficult for Average Joe.
> 
> Just because a "programmable" configuration system could be external
> to the httpd process doesn't mean it can't be integrated into the
> source/binary releases (like all the existing support tools) and
> the apachectl script.

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?

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.

> In that case, Average Joe wouldn't know it is external, but Smart

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

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

> Jill could plug in a configuration generator that used her language
> du jour, or talked to her database, or talked to an LDAP server, or
> whatever.

Fine. She can do this. But Joe uses builtin, native Apache functionality.

> In fact, I suspect some (many?) larger Apache installations already
> do that sort of thing. I know we at HomePage.com do.

Yah, and I don't. Neither of these facts say anything.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: external config processing

[rb...@covalent.net]

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

We already have this ability.  It's called modules.  People that don't
want to use mod_perl, don't install it.  Mod_perl allows admins to put
perl code in their config files.  This is a feature that is used ALL the
time.  To get rid of this ability would keep people from upgrading to
Apache 2.0.  That's the bottom line.

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

Yes, I agree completely this is a very powerful concept, but sometimes it
just doesn't work.  In the case of mod_perl, we can not provide the same
function in an external parser that we can in an internal one.  This in
and of itself should be a powerful enough argument for us to keep the
ability for modules to hook the config process.

Ryan

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

Re: external config processing

[Manoj Kasichainula <ma...@io.com>]

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

Re: external config processing

[Jim Winstead <ji...@trainedmonkey.com>]

On Apr 28, 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?
> 
> 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.

Yeah, I can't wait until Apache reads mail, either. Or for that
silly 'cat' utility to grow up and learn how to be a webserver.

Yes, I'm being extreme. You're just drawing your artificial line
further away from the core web-serving functionality. Doesn't make
it any less artificial.

Why is there an 'apachectl' script? Couldn't the httpd binary just
as well handle 'start', 'stop', 'restart', 'configtest', etc
command-line arguments?

Jim