httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: external config processing
Date Fri, 28 Apr 2000 09:23:38 GMT
On Wed, 26 Apr 2000, Manoj Kasichainula wrote:
> On Wed, Apr 26, 2000 at 03:50:45AM -0700, Greg Stein wrote:
>...
> > One option is to toss any notion of hooks and simply allow reading
> > configuration from a file or a pipe. When a pipe, it would typically be
> > the output of some thing that is processing the source config file.
> 
> Then how would restarts work?

Unrelated.

No matter what config system is used, a restart can read the new config
(and validate it), then start switching subprocesses/threads over to the
new config. Once everything has switched, then it destroys the old config.

> I see nothing wrong with having Apache read config from the
> filesystem, and in fact, I want there to be that required interediate
> stage. I'd like to see config parsing and Apache start/restart become
> two completely different steps. Then, for example, if the Perl in the
> unpreprocessed configuration is buggy, you'll know it before you try
> to make Apache use it.

This can happen whether the config comes from the filesystem or a pipe.
The concepts are independent. 'nuf said on this.

>...
> > 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."
> 
> Well, I have two reactions to that. First, as Jim said, there's
> nothing stopping us from including one or more external config parsers
> with our code.

Yah, and why must it be external to Apache if we have to write the damn
code? It doesn't improve modularity, it does increase complexity, and it
buys us little.

Basically, you trade off a hook mechanism for reliance on external
processes. The latter has more failure points than the former. I prefer to
eliminate failure points.

>...
> > People want to install and run. External processors and config
> > manipulators simply make that more difficult for Average Joe.
> 
> Not if our scripts do all that work for them. We're going to have to
> document the restart process as using a script anyway, because of the
> SIGUSR1/SIGWINCH split.

Failure points. You're increasing complexity and trying to solve it by
throwing even more tools at the problem. Bleck.


Cheers,
-g

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


Mime
View raw message