httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: config hook design
Date Fri, 28 Apr 2000 09:43:48 GMT
On Wed, 26 Apr 2000, Manoj Kasichainula wrote:
> On Wed, Apr 26, 2000 at 03:27:49AM -0700, Greg Stein wrote:
> > 2) Hook the insertion of a node into the config tree
> > 
> >    - independent of the input mechanism
> >    - the file is not available
> >    - provides for "immediate" execution of directives
> >    - useful for AddModule/LoadModule
> My opinion is still solidifying on all this. I'm in random rambling
> stage.
> Are there cases where this is useful besides these two directives? I


I'm still trying to get a handle on how logging configuration SHOULD be
done. Once that has gel'd, then we'll see where/how it fits. At the
moment, I believe the logging will also make use of the insertion-time

> think it gets confusing to have ordering skewed with this kind of
> hook, so I'd rather avoid it. Sounds like you would too.

No skew. Just different execution times. Ryan continues to describe this
kind of stuff as separate passes over the tree. I fold construction and a
followup pass into one process (since this produces the same, net effect).

> I'm actually leaning towards more of a configuration language where
> ordering is irrelevant.

This can only occur to a point. There are at least three things that I can
think of to monkey this:

1) user/group and the corresponding setuid/setgid. this may get worse
   if/when we start forking children that have distinct uid/gid pairs.

2) module loading

3) log configuration and opening

> ISTR that this isn't the case in the current
> config structure, but I'm not too clueful on what's in the code right
> now.

The tree is ordered according to the input file. It preserves the
*existing* semantics of Apache's ordered configuration file.

Remember: we're taking steps. At this point, it was very important not to
alter Apache's semantic model of configuration. That can/will come later
once the kinks are out of this step (witness the problem in building the

> Now, the question is then how to allow LoadModule/AddModule
> constructs. If we didn't have to tell the user when there were unknown
> directives present, this would be easy enough, but unfortunately, I
> guess we have to prevent users from shooting themselves in the foot.


> Hmmmm, though that could be the job of our config file
> preprocessor...

Bleck. You're talking about developing whole new tool suites just to avoid
a simple, optional hook in the code (for *others* to take advantage of;
not us).


Greg Stein,

View raw message