I actually considered proposing YAML for the config files—there's something to be said for the simplicity of a guaranteed-static config!—, but I just can't resist the allure of the turing tarpit.
Srsly: my favorite mailer daemon is Exim, whose configuration basically involves writing code for how to handle things; my lighttpd configs rely on include_shell; back when I used sphinx for full-text search, I relied on the ability to have the config start with a shebang and built my own Debian-style conf generator for it. Many of the daemons that don't provide that sort of thing as an option end up with config generators (rsyslog, nsd, etc.) and mildly annoy me because I forget to regenerate the config when something relevant changes instead of it being automagical.
Possibly that just means my programmer side holds a little too much sway over my sysadmin side, but code-based configs are just ... so ... handy. But hey, if there's a consensus on the configs being not-Perl, I'm happy to go that route, too.
no subject
I actually considered proposing YAML for the config files—there's something to be said for the simplicity of a guaranteed-static config!—, but I just can't resist the allure of the turing tarpit.
Srsly: my favorite mailer daemon is Exim, whose configuration basically involves writing code for how to handle things; my lighttpd configs rely on include_shell; back when I used sphinx for full-text search, I relied on the ability to have the config start with a shebang and built my own Debian-style conf generator for it. Many of the daemons that don't provide that sort of thing as an option end up with config generators (rsyslog, nsd, etc.) and mildly annoy me because I forget to regenerate the config when something relevant changes instead of it being automagical.
Possibly that just means my programmer side holds a little too much sway over my sysadmin side, but code-based configs are just ... so ... handy. But hey, if there's a consensus on the configs being not-Perl, I'm happy to go that route, too.