httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Config tree code finished.
Date Mon, 24 Apr 2000 13:11:23 GMT
On Sun, 23 Apr 2000 wrote:
> I had another thought about how to handle this problem.  This is my
> favorite method so far, because it handles every case I can think of.  The
> solution, ignore these problems  :-)

If we allow modules to work *only* against the tree, then we
(theoretically) have a loss in functionality. Fine by me, but in 1.3,
modules could read lines directly from the file. The lines that we read,
process, and store into the tree have lost information (leading/trailing
whitespace is stripped, lines are joined, quotes around args are removed,
etc). This could actually be problematic for Perl. Consider:

    "this is a long line of text" .
    "another chunk of test";

When we store that, the quotes are missing. As a result, when we feed the
text to Perl, it will bomb with a syntax error.

IMO, we need to allow two things:

1) hook during the reading process
2) post-process the built tree, before command processing

> Let the modules handle this stuff themselves.  This is the perfect
> application for the pre_config hook.  Let me give you three examples (the

We would rename the hook. pre_config is a poor name for this. Note that
you are describing option (2) above.

> three I have been able to think of):
> mod_macro:
>     read the config, which defines a specific macro.  Mod_macro's
> pre_config hook is called.  It does a search of the tree for that macro,
> replacing the macro with the appropriate sub-tree.

This should work fine for mod_macro.

> mod_core's include directive (currently brokem beyond all belief):
>     read the config, which includes another file.  Mod_core's pre_config
> hook is called, it does a search of the tree for an include directive, and
> then opens the new file, and creates a new config tree from that file, and
> adds it into the tree.

For include: this will also work fine.

> mod_perl:
>     read the config, which has perl in it.  Mod_perl's pre_config hook is
> called, which searches the tree for <Perl>.  If found, it launches a perl
> interpreter, and re-opens the config file, seeks to the correct line, and
> slurps in the appropriate perl code, removing the old perl section of the
> config tree.

Not going to work (see above). mod_perl has to hook the read process.

> This obviously has a massive improvement, because currently each module is
> searching the tree, and the core could do that for the modules, but that
> is an improvement that could come later.
> Thoughts?

You complained about my design for registering functions which can be
invoked during the reading (option (1) above). You said that searching the
list at each read of a directive would be burdensome. That's bunk. You're
suggesting the same thing, but simply deferring it to a different point in
time. I say check for Macro/Use/Perl/AddModule/Include/etc at the time of
reading. You say that each module is going to do a tree walk and do the
same comparison. I'll optimize your idea and say the tree walk is combined
and we search for the different directives within that shared loop. Okay,
so why do we have a separate tree walk when we could do the same thing
during the read process? :-)

The post-process is definitely valuable and should be kept. It can
certainly do a walk, and it will be the most portable solution (across
config input mechanisms). Hooking the reader will be very specific to a
particular config syntax, but is necessary for certain types of "heavy"
config processing.


Greg Stein,

View raw message