httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: Configuration modules...
Date Sat, 08 Apr 2000 17:14:36 GMT
On Thu, 6 Apr 2000, Ryan Bloom wrote:
> 1)  Build an internal represenation while we configure the 
> server.  --  In this step, the internal rep is not used to 
> configure the server, we are just building it as we read in
> the config file.  The internal rep is discussed later.

I see one big initial problem with this structure...

1) RAW_ARGS - this doesn't fit into anyone's config model.  If
   you think about the simple little Options statement, we may
   be better off with a two level structure, where options fits
   in the concept of a container, with the individual args, i.e.
   All, ExecCGI, etc... handled as end-nodes.

   We fundimentally need to kill RAW_ARGS before we can discuss
   anything about this new model for httpd vs. XML config.

We still seem to be discussing data structures.  I really think,
when it comes to the dozens of permutations that specific modules
may require, that we should be discussing an api.  We have a 
parsing api that will pass two args (we ought to name them for
future xml directions), but we need a construction api that
will return two args from the same function in the module.

In this way, the config api can call out to the modules as the
tree is reconstructed.  mod_info is useless if all it prints is
the existing script.  Other modules have made assumptions, we
need to note them, such as Backflip On, Backflip Off, or most
important, Backflip Inherited.  It's the inherits that generally
trip users up, so spell them out.

A _really_ effective mod_info would be splattered with <A NAME=x
and <A HREF="#x to walk the inheritences up the tree, and find 
where the inference was inherited from.

I'm not against a new data structure, I'd just like to see some
api activity with the callbacks to allow a config to 'build itself.'


View raw message