httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: config hook design
Date Fri, 28 Apr 2000 11:51:27 GMT

> > 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.

Unfortunately, yes.  But, without processing directives, the read/build
step would be fast, so this is really a wash.

> *) 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 ...

The problem is you have no way of knowing how a container wants it's
information stored.  I agree this causes an annoying re-walk step, but how
else do we keep <perl> sections un-parsed?  Without forcing mod_perl to go
back to the file?

> *) 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.

This can't be folded into step 1.  Take the example of a LoadModule within
a <ifMod> container>  Now, not only are you executing the LoadModule
directive while reading the file, you are also executing any branching
directives while reading the file.  You're adding complexity to something
that can easily be made simple.

Yes, I agree that three passes through the tree sucks, I would love to
minimize this, but I would rather write the code, and make it work before
we start optimizing.  The more alpha's we have with a broken config
because we can't decide the "right" way to do this, the slower people will
be to adopt 2.0.

> > 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.

Yep, I'm an idiot.  :-)

> 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.

IMO, it doesn't work, unless you start loading modules when you encounter
a LoadModule command, which as I stated above, is a slippery slope,
because once you start executing one directive at load time, you also have
to execute others.

> > 5)  Third pass, actually walk the config and configure the server.
> My step (4), which is really just current behavior.


> > 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

Essentiall greg, we are saying the same thing, we just differ on where and
when the optimizations should be done.  Let's code it without
optimizations, so that module writers can use it, and optimize it when we
are done.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message