httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Pool <>
Subject Re: A Somewhat Incoherent XML Configuration Proposal
Date Mon, 07 Feb 2000 00:04:10 GMT
On Tue, Jan 11, 2000 at 09:36:12PM +0000, Ben Laurie wrote:
> I've been thinking about this on and off ever since it was first mooted,
> and I think I have the germs of an idea. First off, there's The
> Problem.

> The Problem is that each module should really have a free hand to define
> its own XML, but if it does that, how do we know which module to feed it
> to? 

I think the solution most in tune with XML would be to use XML
namespaces, and to allow each module to define its own tags within its
namespace.  The XML RFC lays down some rules about how applications
should handle tags they don't understand, how to define namespaces and
so on. 

See for example

(I do sometimes think w3c doesn't always pay enough care to
simplicitly, and perhaps this is an example.)

> Well, I have a simple solution to that. We wrap module-specific
> directives up in chunks that clearly belong to the module, like so:

The problem with that approach is that it conflates ``which module
defined this directive'' with the semantic structure of the

  <Directory name="/usr/doc">
    <autoindex:ReadmeName filename="README"/>
    <expires:ExpiresActive enable="yes"/>
    <expires:ExpiresDefault seconds="38400"/>

> Going a little further, I think it would be possible to generalize the
> VirtualHost stuff, at al., into "context variables", along these lines:
>   <Module name="if">
>     <If host="" port="1234">
>        .
>        .
>     </If>
>   </Module>

Instead I would write

  <LoadModule module="mod_if"/>
  <if:ListenPort host="" port="1234">

The parser should handle most of the work of this for us.

At any rate, this seems like the correct XML way to do it.  That
doesn't make it the best, of course.

> the resulting configuration would be cached against the values of the
> context variables, so when the same setup occurred, the configuration
> would be reused...
> Not only would this be rather flexible, but I suspect it would remove a
> good deal of the arcane code that currently handles vhosts, locations,
> files and so forth...
> But before I elaborate on this basic scheme, I'd like some
> feedback...

There you go.

Martin Pool, Technical Support Engineer, Linuxcare, Inc.
+61 2 6262 8990,
Linuxcare. Support for the revolution.

View raw message