I was very excited about the new plugin architecture. It was going very well, and several of the more "built-in" modules had been successfully converted to full blown standalone ones without much ado - including Lenel OnGuard's plugin and the one I'd created for talking to Simplex panels (well,
listening to would be nearer the mark.) I started attempting to rebuild the MODBUS module as a plugin, and then decided to try to bring as much of the original code over as possible. That, however, is when I ran into the first new snag in this plugin architecture. The Base Object Name.
In Buscom, you have some core functionality that is accessed by top level items through vterm (the command line interface) such as
channel or
xmq. When you load a plugin, the plugin adds it's own base object as part of the linkage process, so that buscom's command handler knows what commands to pass on to the plugin's command handling routines. In the past, these have all been single items, but with the modbus module, I had designated multiple top level objects, including
rtu and
datablocks. This presents a problem, since you can at present only have one top level base object name.
There are a couple of ways to work around this:
- Prefix all commands with modbus - IE: modbus rtu 1 show
- Modify the base object designation to allow multiple items separated by a delimiter - IE: modbus|rtu|datablock
- Something else?
Personally, I am leaning towards the second option because it keeps in line with the rest of Venturii's norms, and offers the most flexibility for this and future plugins. It does, of course, require modification to the buscom code itself to strip out and parse the multiple base object names, but that is minor and trivial, really. Good. I'm glad that's settled.
