You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Pool <mb...@linuxcare.com.au> on 2000/02/07 01:04:10 UTC

Re: A Somewhat Incoherent XML Configuration Proposal

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

  http://www.w3.org/TR/REC-xml-names/

(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
configuration. 

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

> 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="somewhere.nowhere.com" port="1234">
>        .
>        .
>     </If>
>   </Module>

Instead I would write

<Apache>
  <LoadModule module="mod_if"/>
  ...
  <if:ListenPort host="somewhere.outthere.com" port="1234">
     ...
  </if:ListenPort>
</Apache>

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
mbp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.