I wanted to thank all those users who have commented during the past three (!) years on config format questions. I have consolidated all input and hope I have come up with a decent solution. Obviously, not everyone will like everything, but I hope I could find a good compromise.
So far, my blog (and the rsyslog site) has the best glimpse at the new format:
http://rainer.gerhards.net/2011/07/rsyslog-6-3-3-config-format-improvements.html
It is compatible with the old legacy format, supports simple control-flow structures (no loops, by intension) and builds heavily on name value pairs for things like actions, inputs, global settings, …
A real-world sample I used for parser development can be found at the rsyslog git web.
You’ll also find the grammar files inside that source directory in the git tree. It may be interesting for those used to flex/bison. My next step is to develop the necessary code for the name/value pair objects. That requires some more plumbing inside the core and changes to *all* loadable modules. Sounds like a lot of work, but I still hope to get this done before the summer break.
I have also started thinking about v7. It will contain a tree-based execution engine, which potentially offers even higher speed and far more options for configuration. This change is too big to make it into v6. Note that v6 will support “if .. then” and probably “if .. then .. else” but not nesting of these statements — because the rule engine does not support that. The main goal for v7 is to support nesting, including the (considerable) relevant engine changes.
I hope the new format is useful and does not upset too many. Sorry for the silence on the final selection. Past experience told me that there were too many totally conflicting views of what the format should look like. I was deeply concerned that a broader detail discussion would have derailed this effort again. So I used known arguments and my best judgment to create the final format. Please all be assured that your arguments were deeply considered and extremely useful in getting this done.
For example, a recent mailing list discussion brought up very good argument why we actually needed to support old- and new-style config for include files. It turned out that actually the best way to solve that problem was to actually extend legacy format rather than completely replace it. This has the added advantage that textbooks, courses and a myriad of Internet-HowTos do not need to be rewritten. Besides that, I think that constructs like
mail.info /var/log/maillog
are really hard to beat in simplicity and clearness, so I think it is valuable to have them as part of the config language.
Thanks again to everyone for helping make this happen.
Rainer