httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject config hook design
Date Wed, 26 Apr 2000 10:27:49 GMT
I believe there are three types of hooks into the configuration process
that we can define. These are used for different kinds of capabilities,
have different assumptions (on the part of the code doing the hook), and
operate at different points in the process.

1) Hook the reading of a directive + args from an Apache-style config file

   - this hook will not be available for other types of config files, as
     it is specific to the current format and the configfile_t input
   - provides maximum control over reading/parsing the input file
   - the earliest hook available
   - allows "foreign" syntax in the Apache file (e.g. Perl source)

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

3) Hook between tree construction and tree processing

   - allows modules to jigger the tree at will, before processing
   - macro systems, tree rewriting, etc
   - each hook would walk the tree itself (rather than Apache doing a walk
     and calling hooks; we can't do it given the kinds of changes the
     called function may want to make)

Already present:
4) Mapping directives to "commands"  (the final tree walk)

The reason for separation between (1) and (2) is pretty simple: there are
certain assumptions about the config input when we say "read a block of
text". That implies we are reading from some kind of file, rather than
(say) an SNMP or LDAP configuration database. To continue to allow the
operation of mod_perl, the (1) hook is required.

(2) is required to properly hook things like AddModule and LoadModule
(rather than gumming up the process with special cases). This is also one
of the easiest places to hook (it doesn't involve tree walks). Note: we
shouldn't really be encouraging hooks at his level -- running commands
immediately (rather than in (4)) is usually not required.

(3) is the best place for macro systems which need to examine and process
the whole tree. Theoretically, these hooks should probably have some kind
of ordering (eval macros before running mod_tree_mangler).

The actual APIs for these things should be pretty straight-forward, so I'm
going to detail them here. The ideas are the part in question :-)

Note this solves the problem that I raised about mod_perl reading text
blocks. Since LoadModule is invoked during construction, then mod_perl
gets loaded and can install (1)-type hooks. Those can read the text block
and drop it into


Greg Stein,

View raw message