httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: thoughts on a new config language
Date Sat, 23 Aug 1997 07:27:59 GMT
On Fri, 22 Aug 1997, Dean Gaudet wrote:

> Definately not 1.3 ;)

No, but maybe 3.1 :)

> Ok, so I bitch about the config language ... and I should back up my
> bitching with at least a message describing something I think is better.


> Anyhow that should be enough to get the debate going.

WARNING: This message starts with Dean's idea, and then goes off into
an odd world that only exists in my imagination. You've been warned.

I think this is an interesting idea. I'd like to see a more detailed
description of how your scopes relate to how the module's configurations
end up when it finally comes time to start the server, but I kinda like

I think, though, that you're better off making the *config file* format
secondary, instead of primary. In other words, instead of defining a
grammar, define the low-level configuration structure, and write some
APIs on the C side of things to deal with it. It looks like your idea
basically is this (and I'm making up terms):

The configuration consists of a list. This list contains a number of
entries, each of which has a named label. This label can be either
point to another another list (in which case you continue recursively),
or the label can be the key to a key/value pair, which contains actual
configuration information. The labels are all one-word text strings, the
possible values of key/value pairs are dependent on the specific key, but
are some sort of expression (see Dean's email for a good explanation of
possibilities - ints, strings, regexes, ipaddrs, lists of the previous -
oh, and booleans, with Dean forgot, and probably a few others)

That seems like a pretty simple way of defining the configuration of
Apache. Then you can write, to that API, any method of configuring
Apache. You could writer a parser to use your new grammar, with lex and
yacc and such:

directory {
    match "/abc";
    core { hostnamelookups off; }

You could write a parser that used the current style of Apache

Match "/abc"
Hostname-lookups Off

(obviously existing Apache config files wouldn't work, but most users are
probably more comfortable with this than a C-style syntax where they have
to worry about semi-colons and bracket matching and things)

You could write an HTML-based configuration utility that showed you this
in some format. Or use Java (though obviously it would have to have a bit
of C to talk to Apache's API).

Or, even better, this scheme maps directly into the form used by the
Windows NT registry. And so on. It's simple enough that any configuration
tool can use it, but still powerful enough to do everyhing we need to do
with it.

And the modules wouldn't care. They would just define their directives
using an API that only gave them access to the very basic constructs
(lists, key/value pairs), and you could plug in any tool you wanted that
configured Apache.

One problem with GUI-based configurations is that they're often
impossible to have a file-based configuration, because the files are
machine-generated. It's likewise hard to write a GUI for a text
file-based config system like Apache, because it's hard to fit a GUI into
the constraints (and oddities) of a text-based system.

So I think we just make the configuration of Apache blind to the
user. Okay, so you wouldn't be able to take your text files and just
magically switch to using a GUI (unless that GUI tool supported importing
the text file format you're using), but I don't think that's a big
issue. Apache isn't that tough to configure, and it's likely that you're
likely to stick with one tool once you start (how often do you switch
text editors, for example? And you don't expect vi to be able to read
your .emacs file)

Anyhow, Dean, I like your idea. And I think mine might be a good way of
implementing it. And making happy those people who want to be able to
configure Apache with the NT Registry, or with SNMP, or whatever.

-- Alexei Kosut <>

View raw message