I also don't mind the current config file, but I've been using Apache for more than 10 years so I've probably lost all perspective at this point. Having the config file in Lua would certainly make it eaiser to automate, validate and document though.

mod_perl already allows for a totally dynamic configuration which should be sufficient in terms of automation.

The documentation is quite perfect already and would IMHO lose quality if the syntax changes this drastically.

The only point I'm willing to hand you is the validation argument, although the current parser seems to be doing a decent enough job already.

No. Discussions like these feel to be motivated by artistic considerations instead of practical ones. Think of all the external documentation such a step would invalidate. Books, Tutorials, Blogs. And think of the external addon modules that would probably break because of this.

Remember the 1.3 => 2.0 switch and how long that took and consider that 2.0 actually had some real advantages compared to 1.3.

Yes, but, my point was that I see it as very unlikely to be adopted.

"The documentation is quite perfect already"

Sure it's well-written but "perfect" may be a stretch. Having a more consistent syntax would allow the documentation to be much more terse.

The current documentation reads like a manual, which is great. What's being proposed would mean that the documentation could be presented as a manual, AND as an API.

"The only point I'm willing to hand you is the validation argument"

I think you should hand me "automation" as well. :-) Writing a tool that interprets a Lua config file would be trivial. Writing a tool that interprets the current Apache config is not.

Anyway I'm not really advocating this change. I simply find the proposal interesting because I do a lot of programming with Lua and it's nice to see it get some high-level recognition.

I think it's too bad that people seem to be diverging towards either a crappy, barely readable data format or full-fledged programming languages. The advantage of XML is that it's a well-specified and reasonably flexible way of representing structured data. You can interpret an XML document as code (e.g., XSLT) but basically XML is just data until you say otherwise. Configuration file formats should be dumb. You shouldn't be able to program your configuration file to play chess. The only significant downside of XML is its verbose and barely readable syntax, and you don't need a configuration file that has its own byte compiler and runtime system to provide readable syntax.

Configuration isn't code, and I don't really think trying to make it such is necessarily a good idea - I suspect it seems superficially attractive to developers but with my sysad hat on it really doesn't seem wise.