Re: Cross platform, multilanguage plugins

What kind of application are we talking about? Especially, what kind of operations should the plugins be able to do? Should plugins have their own GUI, be integrated into the main app's GUI or don't they have a GUI at all?

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

This suggests you either want a C-level interface (i.e. a dynamic library) or some kind of language independent interface (preferably text based - I might even go for XML)

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.

Do you also want to have plugins running on remote machines?

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.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re: Cross platform, multilanguage plugins

Replies are listed 'Best First'.
Re^2: Cross platform, multilanguage plugins by TGI (Parson) on Feb 13, 2007 at 23:24 UTC
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: App collects data from sensor App calculates any custom fields from field plugins App checks for any conditions that would cause an alert 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	[reply]

Replies are listed 'Best First'.

Re^2: Cross platform, multilanguage plugins
by TGI (Parson) on Feb 13, 2007 at 23:24 UTC

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:

App collects data from sensor
App calculates any custom fields from field plugins
App checks for any conditions that would cause an alert
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

[reply]