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 Tue, 25 Apr 2000 03:14:57 GMT
On Mon, 24 Apr 2000, William A. Rowe, Jr. wrote:
> I don't think we need to marry the module to the config.  This is
> backwards to the starting point, IMHO.  We need a more flexible
> parser extension API.  How do you extend in the future, without
> bastardizing the new tree structure?

We do not necessarily need a parser *extension* capability. An alternative
is to allow entirely different parsers.

Match that with the ability to operate on the post-parse output (the tree)
so that modules can be independent of the parser mechanism.

> This is why I suggested an api in the first place.  This tree,
> while a good thing, is going to box us in a corner.

This is outright nonsense, to be frank. The Apache configuration is
semantically a tree. We have modelled it as a tree.

> The example you cite would be closer to a <pre> block in 
> html, where the text is unprocessed.  This should be trivial 
> to implement, and isn't really part of the problem.  If you need, 
> extend the flags to accomodate raw blocks.  We don't suffer here 
> from nesting, so it shouldn't be difficult.
> Please don't use a whole glob of API stuff to solve the raw
> block problem.

Nobody has suggested a "whole glob". I've suggested a couple mechanisms
that people can use to operate at different levels in the configuration
process. Each are pretty simple.

"extend the flags" you say. How? What specifies the flags? A module? Feh.
The module hasn't been loaded. Okay, how do you get the module loaded, so
you can see the <pre> flag? You follow my suggestion for allowing modules
to hook the creation of nodes in the tree.


Greg Stein,

View raw message