httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Configuration modules...
Date Thu, 06 Apr 2000 18:30:56 GMT

So, there has been some talk of adding configuration modules to Apache
2.0.  Well, as Greg Stein mentioned last week sometime, we have some
thoughts on how to do this.  I will try to explain the concept and the
steps that we envision for doing this, and then I will sit back and await
the searing heat of flames.  :-)

The concept.  The old 1.3 configuration syntax is great, for what it
does.  But it really requires that all the information is stored on one
machine.  There has also been talk of moving to an XML configuration
scheme, but nobody has been able to design one that we all agree on.  So,
the answer is the ability to configure the server using a different
language based on configuration modules.  :-)  (please, no hitting the
programmer with bats)

The steps to acheive this.  We have basically come up with a nine step
process to put configuation modules into Apache 2.0.  Please note, not all
nine steps need to be completed before 2.0 is actually released, but the
full potential of configuration modules won't be realized until they are.

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.

2)  Walk the internal representation to configure the server.  -- This
basically removes the actual configuration from reading the config file.

3)  Encapsulate step 1, so it can be replaced by other modules.  -- This
is basically just creating the API for Configuration Modules.

These three steps must be done first.  After these are done, there are two
more sets of three steps that can be done at any time.

Set 1
1)  XML schema for modules.  -- This is basically a way of explaining
modules and directives in XML.  We will keep support for declaring modules
using the current method for at least the 2.X series.

2)  Define callback API -- This is an API that config modules can use to
add items to the internal representation.

3)  Add validation.  -- This allows configuration modules to actually
check that the arguments given to directives make sense, and report errors
if they do not.

Set 2

1)  Loadable CFG modules.  -- command line argument that specifies a CFG
module to use (dynamically loaded).

2)  CFG module choice. -- (I don't remember what this was all about.
Greg, do you?)

3)  Multiple CFG Input files. -- The ability to change your config module
while you are parsing a config file.

Okay, so those are the steps to actually get this stuff into the server.
So what does the internal rep look like?

Internal rep:

the internal rep is basically a tree 

N - N - N ...
|   |   |
|   |   N ...  
|   N ...
N ...

The tree has a max depth of four.  The top level is the global server
config.  The second level is the virtual host config.  The third level is
directories and locations, and the fourth is files.  Obviously, if the
configuration doesn't have virtual hosts, then the tree is only three
deep.  :-)

The nodes in the tree at least initially look like:

ap_directive {
    char *name;
    ap_table_t *args;
    int linenumber;       (This is most likely temporary)
    ap_directive *next;
    ap_directive *parent;
    ap_directive *first_child;

The linenumber field can go away as soon as we have added validation to
the configuration modules, because in the initial version, it will be used
to output a line number when there is an error in the config file.

That's it.  I probably haven't described something well, so feel free to
ask questions.


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

View raw message