thoughts on a new config language

[Dean Gaudet <dg...@arctic.org>]

Definately not 1.3 ;)

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.

I am partial to languages in which whitespace is freeform, and end of
line is not significant.  For example, I like what ISC has done with
BIND 8 and with their DHCP server; both of which are similar to gated's
config language.

I like to have well defined tokens, and building blocks such as
address-match-expression or regular-expression which are reusable,
and provided by the core.  With these things standardized it makes it
easier for the user to know how to use a new command.

Here are some examples, I'll try to cook up a BNF grammar for it.

old:
    MaxKeepAliveRequests 100
    MaxRequestsPerChild 1000

new:
    core {
	max-keepalive-requests	100;
	max-requests-per-child	1000;
    };



old:
    CustomLog access_log "%this %that %other"
    # pretend this directive exists
    BufferedLogs on

new:
    mod_log_config {
	log {
	    filename	access_log;
	    format	"%this %that %other";
	};
	buffered-logs	on;
    };



old:
    <Directory /abc>
	HostnameLookups off
    </Directory>

new:
    directory {
	match "/abc";
	core { hostname-lookups off; }
    }

I'm trying to introduce scoping.  A module-name introduces a scope in
which all of the directives for that module are valid.  A directive
can introduce a scope in which its subdirectives are valid.

It seems possible to make scoping optional provided there is no ambiguity.
That is, provided no two modules define the directive buffered-logs
then you could use buffered-logs without a scope.  But as soon as two
modules define buffered-logs then any use of the token "buffered-logs"
would be an error unless it was scoped.

Expressions are those things to the right of directives, and we have
at least these standard expressions: integer, string, regex, ipaddr,
or list (which is a list of expressions).  I think the syntax for these
should be something like:

    int-expr	:	'-' digits+ | digits+

    string-expr	:	" or ' delimited

    regex-expr	:	m#regex#

    ipaddr-expr	:	d.d.d.d | d.d.d.d/n | d.d.d.d/m.m.m.m

    simple-expr	:	int-expr | string-expr | regex-expr | simple-expr

    list	:	simple-expr
		|	'{' simple-expr, list '}'

(Yes lists can nest and be lisp-like.)

For a module to specify its directives and scopes it's probably a bit
difficult to do a static structure initialization, so there would need
to be a little initialization phase where modules can build the parsing
structures needed.  It shouldn't be too hard to build new modules once
there are a few examples to look at.

Yes this means I want to use lex/flex and yacc/bison.  We can supply the
already lex'd and yacc'd files with the distributions though.

Anyhow that should be enough to get the debate going.

Dean

Re: thoughts on a new config language

[Alexei Kosut <ak...@organic.com>]

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
it.

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
configuration:

<Directory>
Match "/abc"
<Core>
Hostname-lookups Off
</Core>
</Directory>

(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 <ak...@organic.com>