httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Configuration modules...
Date Tue, 11 Apr 2000 16:04:35 GMT
> Ryan Bloom wrote:
> > Internal rep:
> > ------------
> > 
> > the internal rep is basically a tree
> > 
> > N
> > |
> > 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.  :-)
> Since we now have pluggable protocols, I'd suggest that we'd need
> something slightly more abstract that this - perhaps the model I've
> mentioned before would find acceptance here since it is only used at
> config time and not runtime: i.e. use conditionals instead of artificial
> constructs like "virtual host", "directory" or "location". This would
> also give flexibility in order of processing. OTOH, I can't quite
> imagine how one parses that into a runtime config, so I'm struggling a
> bit.

I think this is a bit more extendable than it looks at first glance.  The
four level tree is really very Apache centric, and I'm not sure that four
levels is enough even for Apache.

As the configuration modules patches are created, this will be more
apparrant, but Greg aluded to this stuff last week.  One of the things we
would like to do is describe directives as XML (if modules don't provide
an XML description, the old style will be used).  I am not very good with
XML yet, so forgive this horrible example :-), but we can do something

    <argument>number</argument>        # what kind of args
    <inherit>yes</inherit>             # is this directive inherited
    <conatainer>no</container>         # is this directive a container

If the directive is a container, then we would create a new first_child
when we hit that directive, otherwise it is a sibling node.

I hope that explains where I envision this going, and it allays your fears
that we aren't being abstract enough


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

View raw message