httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: config hook design
Date Fri, 28 Apr 2000 09:53:51 GMT
On Wed, 26 Apr 2000 rbb@covalent.net wrote:
>...
> 1)  Read the config.  As we read the file, we check the directive to
> determine if it is known.  If it is known, we do what the command tells us
> (either parse it to directive/args or use raw text), and store a pointer
> to the function that handles this command (no sense looking it up multiple
> times).  If the directive is unknown, we store the directive as raw text,
> if it is a container read the whole container as one node in raw text.

*) most directives will be unknown unless you have some way to load
   modules *DURING* this process. therefore, you are saying that most
   directives would be unprocessed.

*) we should not store unknown containers as raw text. the contents could
   very well be additional configuration directives. by storing as raw
   text, you require a second pass over the text to parse out the
   directives. this increases the complexity of the process as you
   parse/walk/parse-again/insert-into-tree/walk-child-tree ...

*) I agree with recognizing commands at construction time. This is
   practically a requirement for performing validation -- effective
   validation requires the parser to know when it has just read an invalid
   command. It has the context at that point. Waiting for a separate walk
   of the tree will (typically) lose the context of where the erroneous
   directive came from. We hack this now by storing file/line in the
   directive structure (which is bogus the long run).

> 2)  First pass through config.  Grab all LoadModule commands and load all
> modules

This can be folded into (1) with no effective change in end semantics. A
LoadModule executed during build is effectively the same as a LoadModule
executed in a separate pass. You will still end up with a sequence of
loaded modules, loading in a particular order.

Even better: loading *during* the construction allows more directives to
be recognized.

> 3)  Run pre_config hook for all modules (MPM and standard)

This is my hook type (3).

> 4)  Second pass through config.  Any directive that wasn't caught before,
> catch it now.  This means we find the directive, parse it to
> directive/args or leave it as raw text.  Store a pointer to the directive
> handler.  This would also be the stage where potentially we could have
> modules hook the config phase, so mod_macro or the include directive could
> munge the tree here.

mod_macro occurs above.

IMO, your argument processing occurred during your step (1). In the long
run, we're going to do it there for proper validation. May as well
design/specify it that way.

> 5)  Third pass, actually walk the config and configure the server.

My step (4), which is really just current behavior.

> This is very very close to what others have suggested, so it is not my
> idea, it is just the one I like the best.  This also allows mod_perl to
> add perl into the config file without hurting us or making the config
> ugly.

Not quite sure about this; comments were above.

> I thoroughly dislike the qmail approach for Apache.  It just doesn't fit
> well with what Apache does IMHO.  It also breaks all of the tools that are
> currently used for Apache configuration.

Agreed.

Cheers,
-g

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



Mime
View raw message