All the 'real' work gets done in OpenDAX modules. Modules are simple processes. They are not dynamic or static libraries that would have to be linked to the core. They are programs that can be started from OpenDAX or from any other means of starting processes on the system, such as, the command line, shell scripts, cron, atd or even as cgi's from the web server. Fundamentally there are two ways to start a module. Either configure OpenDAX to start them or any other way. There are advantages and disadvantages to both and we'll get to those.
Using processes was chosen for several reasons. The first reason is simplicity. For this system to become popular it must be easy for module writers to get the job done without having to go through a large learning curve for the base system. It should be very simple to write a module that does nothing more than watch a single tag and then send an email when the value changes. A module that requires some fancy messaging might be a little more complicated but a module should only be as complex as it needs to be. It should even be possible to use a shell script as a module. It should also be possible to use Ruby, Python, Perl or other interpreters as modules. Bindings for the libdax library could be written for these languages and entire logic systems programmed with interpreters. Imagine the power of PHP libraries for OpenDAX.
The second reason for using processes is to keep ourselves from reinventing the wheel. Modern *nix style operating systems such as Linux, BSD and OS X are all very good at dealing with and, scheduling processes. Why should we try to get into the operating system business?
Another reason is that there is no requirement that modules must be on the same machine as the server. The module to server messaging protocol uses sockets for communication and therefore can communicate over a network. This should give the system some pretty impressive scalability.
One drawback to using processes is that we are at the mercy of the kernel scheduler as to when modules are run. I don't think this will prove to be much of an issue. Even the cheapest computers will spend most of their time sleeping while running OpenDAX. If there does happen to be some 'real-time' issues that need to be dealt with, they can be handled with kernel drivers and/or custom hardware with an associated dax module. It would probably be impossible to write a module that could count flow meter pulses with the LPT port but it would be trivial to use the modbus module to communicate to a purpose built flow computer. It would also be possible (though probably not trivial) to write a kernel driver that could handle it.
Modules can either be started by the OpenDAX server itself or started by some other means like from the command line or a shell script. Modules that are started from within the OpenDAX core program have a couple of advantages. The starting and stopping of modules is controlled and the default file descriptors (stdin, stdout and stderr) can be redirected. Neither of these features has been fully implemented yet, but they are very important and will be included very soon.
Having the server launch the modules gives the server some control over the modules. It can be signaled as soon as a module dies and since they are child processes the server can send signals to them. When OpenDAX is signaled to quit all the modules that it has started are also signaled to quit. The order that modules start can also be controlled. Controlling the order of module start up allows modules that create tags (I/O modules primarily) to start first and modules that require these tags to exist (logic, interface, alarming etc) to start last.
The ability to redirect stdin, stdout and stderr allow us to use programs that were never intended to be modules. I imagine the first use that I will have for this feature is to use mpg123 as a method to play sounds from the computer sound card. This is a poor man's tone generator. Actually it's for the poor man but would have more features than tone generators that cost thousands of dollars.
The disadvantage to modules started from the OpenDAX server is that they would be disconnected from the controlling terminal. This is because OpenDAX would usually be running in the background as a daemon process. It is possible to run OpenDAX in the foreground and all processes could printf() to the console but this would usually only be used for debugging. A user interface module would probably be started outside the OpenDAX server for this reason.
Modules that are started within OpenDAX do not have to be automatically started at run time. Their configuration can be stored in the list and started by message from another module based on some event. Modules can be configured to run once at start up and die if they are allowed to. They can also be restarted by the server if they die when they are not supposed to. The server is also smart enough to know the return value of the module and can make these decisions after the module exits.