While this may sound like it's coming out of nowhere, Lua was designed primarily for use in extension/configuration, and has been used in production this way for about fifteen years. It's a scripting engine, config file format parser, JSON-like data format library, etc., all in a library a bit smaller than SQLite.

The lua interpreter is essentially just a "code = read(); f = compile(code); print f()" loop written in the C API, with better error messages. The C API is primary, not the standalone language, and using it with existing C projects is quite easy. (As a language, it's very much like a twin of Javascript that was able to mature for another decade, rather than suddenly getting standardized. Most of the flaws Crockford describes in "Javascript: The Good Parts" were fixed in long ago in Lua.)

More specifically relevant to apache, running code in a sandbox is trivial. You can use setfenv() to control the environment, global packages, etc. available to any code. If code shouldn't access the compiler, OS or debug packages, etc., just pass it an environment without them.

There's also a chapter in _Lua Programming Gems_ (http://www.lua.org/gems/) (it's "Lua as a Protocol Language" by Patrick Rapin, no sample PDF though) that shows how to set up a simple filter at the bytecode level to block loops, guaranteeing that code will always terminate. With a few minor changes, it's completely safe to use as a network protocol language.

Surprised to see so much discussion on that. Instead, would expect someone to simply implement it, throw it on the table, and provide instructions for building it into your own apache.

If it catches on, then you have a replacement to the current config syntax.

That said, in my experience, admins are slow to change. There are still sites running Apache 1.3 out there.

I wonder what is wrong with the current way of configuring apache. I might be biased, but I have experience with both lighttpd and apache and I always found the apache way of doing things perfectly fine and actually prefer it to the kind-of procedural style of lighty.

Let's just hope they don't switch to an XML based configuratino file. We don't need even more filler-code in our configuration files.

XML just isn't human readable (and writable! and, yes, you DO write configuration files here and then) enough to be convenient. IMHO at least.

I prefer the nginx config style over apache2. Why the hell would anyone need a turing complete configuration file syntax?

I like this:

http://thread.gmane.org/gmane.comp.apache.devel/37627/focus=...

> I would like to see the output of configuration be a struct (of structs), and the actual config files are never looked at again (until reload). At that point we don't need to care how it is built, and we can try using lua, vcl, xml, jelly, groovy, windows ini files, or plists :)

I wonder what's going on with this, I just noticed the whole discussion is from early June...

Wait, what?

key=value is really so hard that we need to replace m4 with lua? Honestly? Before you feel the need to flame, imagine if this proposal had been for implementing the config file in COBOL (a language designed to be code readable by non-technical people). Would you still believe it to be a good idea?

What ever happened to wanting to keep things simple?

Tcl's nice for this kind of thing too, as it's really easy to make your own "DSL"'s (or is that passe`?)

    directory "/usr/local/foo/bar" {
        options bee bop doo wah
        if { $someotheroption } {
            order allow deny
        }
    }

Its a neat idea, but I would echo the sentiment brought up in the thread linked that casual users would have a much harder time with a lua config in comparison to the current one.

Its probably a good idea to move in this direction in the long run, but there is always a risk of displeasing your current users.

<Perl>

#!perl

use DBI;

use Blah;

...

push @{ $VirtualHost{'*'} }, {

        	ServerAdmin     => "webmaster\@$domain",
	        ServerName      => "$domain",
                ServerSignature => "Off",
	        ServerAlias     =>  \@aliases,
	        AddHandler      =>  [qw(cgi-script .cgi)],
	
	        DocumentRoot    =>  "/home/$domain/www",

	        Alias           =>  [
			["/cgi-bin/", "/home/$domain/cgi-bin/"],
			["/stats/", "/home/$domain/stats/"],
		],

I think that config files should be simple to write DSLs, and not programming languages. For automation what is really needed is an API exported by Apache via some kind of networking (a TCP socket could do the work) that allows to configure and change the behavior at run-time via a scripting language. This way you have the best of both the words.

It would be cool if we can use runtime variables in Apache's config

Haha I remember Brian from CNN he was talking about this years ago, I guess it takes a lot of momentum to change something as big as apache.

OK, for anyone who hasn't seen it before, this is what "second system effect" looks like just before it gets really ugly.

Should [X] replace its [Y] configuration with [programming language here]?

Maybe. Depends. Is there a way you can try it out?

Reminds me of Zed Shaw's "The ACL is Dead." http://vimeo.com/2723800

I can also see that turning in to a quagmire.