I've forked the OpenDAX code and started working on version 0.2. There was never a release for version 0.1 but I'm going to be making a lot of changes to the code, so I changed the version. Primarily I've decided to change three things and each is pretty major and effects every part of the OpenDAX system, the server, the library and all the modules.
First, I'm going to change the IPC interface to sockets. I've been using a message queue for module to server interaction up until this point but it keeps causing me problems. I was hesitant to do this because it's going to be much more complex but in the end I think that it'll be more flexible and it'll get the code to where it needs to be quicker. Better to change it now while there are only a few modules.
One side effect of switching to sockets is that it makes remote modules much easier. Whether the module is local or remote will have to be configured in the modules somehow. For the moment I'm going to code in a UNIX Domain socket since they are much faster than TCP sockets for the local modules. I'll also have the server listen on a TCP socket and accept connections from the network as well. This way the module handling code will be the same for local modules as well as remote modules.
The second change involves configuration. There is quite a bit of configuration that will have to be in the modules for the new socket interface and there was already some common configuration options (-C configfile, -vvv for verbosity, etc.) and this will add more (IP address, local socket name, etc). It seems appropriate to build most of this into the libdax library. The module programmer will have to set up the module specific configurations and then pass the argc / argv parameters to a library function that will then parse the command line arguments and run the Lua configuration file.
Having more of the configuration built into the library enforces some consistency with respect to the module configuration and it frees the module programmer from having to deal with the common parts. I will probably make this optional so that the module programmer can have the freedom to configure the module however they see fit but there would be some added complexity to make sure that the IPC interface is properly configured.
The third change is in the logging. I discussed it some here. I got a really good suggestion about how to have the library decide what to log and what not to log. I was thinking a hierarchy of verbosity levels. The higher the verbosity level the more got logged. This was getting cumbersome. A suggestion was made to use flags instead of levels. In other words instead of a verbosity level of 5 logging everything configured to that level or lower, the program would use a bit field and each different type of message would be individually configured. For example, major program milestones would be a flag. If that flag was set in the configuration then that log message would be sent to the logger. If not it wouldn't. There would be other flags for function entry points, configurations, communications errors, messages and the like.
This one will be the simplest of the three changes to program but it will effect the most module code. I also think that I'll go ahead and send the logging information to the server through the socket and let the server decide what to do with the messages.
I'm also going to start using the term system log to describe this stuff, because in the very near future I'll have to start talking about user event logging. This is the logging that the user application will need to do. For example, the logging of when alarms are acknowledged, or when a pump was started. These two logging interfaces could be sent to the same place (a database or the console) but they need to be kept separate in the code so they can be sent to different places if the user requires. I suspect that the most common arrangement would be to send the event logs to some kind of database and the system logs to the syslogd service.
I'm going to be taking some vacation from my day job soon to spend some time working on these issues. I hope that I can get the program back to the condition that it is in right now, but with these new features very soon. When it works okay I'll merge the changes back into the trunk.