Return-Path: 
 <new-httpd-return-2275-apmail-new-httpd-archive=apache.org@apache.org>
Delivered-To: apmail-new-httpd-archive@apache.org
Received: (qmail 23710 invoked by uid 500); 11 Apr 2000 22:31:04 -0000
Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: new-httpd@apache.org
list-help: <mailto:new-httpd-help@apache.org>
list-unsubscribe: <mailto:new-httpd-unsubscribe@apache.org>
list-post: <mailto:new-httpd@apache.org>
Delivered-To: mailing list new-httpd@apache.org
Received: (qmail 23699 invoked from network); 11 Apr 2000 22:31:02 -0000
Message-ID: <38F3A78A.E9F3E3FB@algroup.co.uk>
Date: Tue, 11 Apr 2000 23:30:34 +0100
From: Ben Laurie <ben@algroup.co.uk>
Organization: A.L. Group plc
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: Configuration modules...
References: <Pine.LNX.4.21.0004111146040.26758-100000@koj.covalent.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

rbb@covalent.net wrote:
> 
> > 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
> like:
> 
> <directive>Port
>     <argument>number</argument>        # what kind of args
>     <inherit>yes</inherit>             # is this directive inherited
>     <conatainer>no</container>         # is this directive a container
> </directive>

Glark. You wanted to wrap something around "Port", I know you did.

> 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

Somewhat, but I don't quite see how you get from the XML to the digested
server config. Maybe you don't. From where I'm sitting you need XML to
control the parser and C to chew the tree it produces.

Not sure I see why this is better than going the whole hog and writing
the config itself in XML.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html