Plugins can be written in many languages - Perl, C, VB, Python, etc.

If you go for a shared library, you might want to consider SWIG, since you can use it to build a single C interface and generate wrappers for different languages including perl, python and C#.

The mechanism should work on both unix and Windows systems.

I think I'd go with either a C library based interface for complex/dynamic systems, or some kind of XML "filter" system for "single shot" plugins: App -> XML out -> pipe into plugin -> xml response -> read back.

The application (written in perl) is used for environmental monitoring.

The two sorts of plugins we have discussed would

• Define new data fields that are calculated based on existing data. For example if you have air temperature and humidity, but want a dew point field, you can write a dew point plugin, install it and then any sensors that can provide the required fields will magically also provide dewpoint.
• Define an action. The app has the ability to trigger a notification if certain events occur. Right now we only offer one common behavior. We would like to allow our customers to create additional behaviors. For example, an action might be "Send SMS Message". Actions would need to have some UI associated with them.

The two types of plugins need not operate in the same way, as long as they are easy to install.

Plugins only need to run on the same machine as is hosting the main application.

The basic flow of execution would be:

1. App collects data from sensor
2. App calculates any custom fields from field plugins
3. App checks for any conditions that would cause an alert
4. If an alert occurs do any actions associated with the alert.

Worst case, we will be dealing with data collection occuring at most tens of times an hour across hundreds of sensors with tens of fields each. Depending on the connection type, it can take as little as 2 seconds to get data from a sensor, or as much as 2 minutes.

Thanks for the ideas.


TGI says moo

Given your description, I'd opt for stand-alone external executables and a well-defined command-line interface.

One such standard is CGI. I've never heard of it being used by anything other than a web server, but there's no reason it couldn't be. And it's very well supported in all languages.

Another possibility is SOAP. I haven't heard of it being used in this way (fork a process and talk SOAP to it over the pipes), but again, there's no reason it couldn't be done, and the SOAP spec explicitly says any communication medium is fair game.

Depending on how you define, the above could be found to be too resource intensive.

If your application is Apache based, then an obvious avenue is to use Apache modules, such as mod_perl, mod_php, mod_python, etc.

Unfortunately, my app is not apache based.

More research on my part shows that Inkscape seems to use small executables for its extensions.

The question of whether this approach will be "too resource intensive" is rather open. The only way to tell is to try some tests. A big benefit on the resources side is that this approach protects me from memory leaks caused by badly written plugins.

Thanks for your comments.


TGI says moo