I have decided that the way to configure the modules in OpenDAX as well as the OpenDAX server itself will be with Lua. Lua is a small embedded scripting language that has recently been gaining popularity because of it's inclusion in games like World of Warcraft. I've written a lua interpreter module for OpenDAX (daxlua) that uses the Lua scripting language as an interpreter that can interface with OpenDAX. I was so impressed with how easy this language is to include in a program that I rewrote all of the configuration file parsing routines in OpenDAX to use Lua scripts as configuration instead of trying to invent my own or use something like XML.
There are many reasons why using a scripting language for configuration make sense in a program like OpenDAX. The first, and most obvious, is that it's easy. Even the simplest configuration file with 'token = value' that just uses something like scanf("%s=%s"); is more difficult to do than to load a Lua interpreter to parse the same file. However as soon as the Lua interpreter is used it allows control structures to build the configuration.
Substitutions would be invisible to the main application with the Lua interpreter. Loops can be used to eliminate repetition. Filename inclusion could also be implemented with the dofile() function. The possibilities are endless, and it only takes a few lines of code to embed the interpreter.
Another benefit is that since OpenDAX is an automation and control oriented program it stands to reason that there will be great need for customizations and hooks for certain modules. One that comes to mind is the Modbus module. I had intended to write a small macro language for implementing 'on-change' type hooks for database points. Every time I tried it became very evident that it was not a trivial task and I found a different way to deal with the problem at hand. With Lua, writing hooks to swap bytes or to move words from one part of the database to another are as easy as running the interpreter and creating a few interface functions.
There are some drawbacks. The most obvious is the dependence on the liblua library. Since I've already used it in the daxlua logic module and intend to use it as the scripting language in the HMI module it will be required anyway. I think it's worth it at this point. The module developers will not have to learn the Lua API unless they actually want to use Lua in the module. The Lua configuration interface is already built into the OpenDAX API. Besides this is all pretty minor since Lua is very easy to learn anyway.