	Sign In Sign-Up

Automated Event Management

Large software development projects invariably have a need to manage the distribution and display of state information and state changes. In other words, they need to manage their software events. Generally, each such project invents its own way of accomplishing this and then struggles to get all of its components to play the same way. It is a difficult process and not always completely successful. This project helps with that.

AutoEvents completely separates the tasks of supplying the data needed for a particular event from the methods used to manage the distribution and display of that event. Consequently, the programmer writing the code no longer has to worry about that part of the problem. Likewise the persons responsible for designing the event management and distribution no longer have to worry about getting programmers to write conforming code.

It works as follows:

Each component of a large system is assigned a group name. All events are associated with one of these groups and are managed that way. Smaller projects may have only one group, but still.
The programmer determines (in some fashion) that when a certain point in the code is reached, it is appropriate to create an event. He then determines what is to be displayed:
- The associated message (formatting string)
- The arguments to the message string, and their types.
- The severity level (a la <sys/syslog.h>).
- Documentation, supplying an extended description of the meaning of the event. This should be suitable for use in a separate document.
- A name, compatible with C syntax for variable names.
This event is then described in a stylized comment embedded in the code (usually where the event is to be emitted), or it may be placed in a separate event description file. I prefer to embed them in the code.
The programmer then inserts a macro that provides the arguments to the formatting string, but does not provide the string itself. The macro name is derived from the event name, the group name, and the severity of the event. For example, if an error event in the "foo" group were named "mumbled" and its associated format string took two arguments, he would insert something like this in his code:
```
FOO_ERR_MUMBLED_EVENT( count, string );
```
The formatting string is not in the macro invocation because it is known from the event description. In fact, it may not even be compiled into the program. It may wind up in a separate program compiled from a internationalized (translated) version.

That is the extent of the involvement of the developer of the working code. Everything else is up to the developer of the event distribution code.

The source file name and line number can be placed in the argument list for the dispatch routine. Some compilers can automatically create the procedure name, too.
A timestamp can be added when the event is recorded.
The dispatch routine can be as simple as `printf()' or as complex as you may wish.
Events can be selected or de-selected by priority threshholds, sub-group masks or even individual masks. The choice is yours. :-)
String tables can be generated for converting user interface inputs into these bit masks and priorities.
Events below a certain severity threshhold (e.g., DEBUG) can be compiled out of the code completely.
A centralized dispatch routine could keep track of event frequencies and throttle them if they come too often.
A centralized dispatch routine could keep track of certain crucial events and dispatch emails or perform other actions if they come at all.
Separate event display programs could make independent decisions about which ones should be displayed.
The documentation strings alluded to above can be extracted into an event response document that you can rely upon to be complete.

All of these latter issues can be decided upon and re-decided upon without interfering with the original programmer in any way (other than, perhaps, a recompile).

This project is not, however, a panacea. Every large scale project has unique issues that need to be resolved vis-a-vis event management. It may be necessary, for example, to dump the data into a circular buffer and return immediately because the comm driver cannot afford to wait for the formatting and dispatching of the event to complete. What this project is, though, is a good framework for building a complete, consistent and well documented solution.

I have a base skeleton that worked for me in getting a couple of projects started with AutoEvents. If you are interested in helping to flesh it out and helping me to document how it works, please email Bruce Korb and I will be happy to share it in its current pre-alpha state. :-)