search

licq-im / licq

An instant messaging client for UNIX
http://www.licq.org/
16 stars 4 forks source link

Pluginbase as object #3

Closed flynd closed 13 years ago

flynd commented 13 years ago

The new plugin base exports only a single symbol which is a structure containing everything Licq need to know to load the plugin.

The exported structure contain a pointer to a factory function the PluginManager can call to create a plugin instance. The plugin instance must inherit from either Licq::GeneralPlugin or Licq::ProtocolPlugin which specify the interface for communicating between the plugin and Licq as well as other plugins. This inheritance allows future extensions to the plugin interface to be made without having to export additional symbols.

This should also allow plugins to communicate directly with each other. For example, if a protocol plugin has a public header file, a GUI plugin could cast the plugin pointer to the protocol plugins type and access additional features not supported by the Licq daemon. (This might be a way to simplify the separation of the ICQ protocol from the Licq daemon without adding generic support for all ICQ specific features.)

The exported structure also contains the Licq version the plugin was built for. Plugin loading is only allowed if the Licq version matches with the daemon. This should catch differences between the plugin and the api that could lead to strange behavior or crashes. It is assumed that the last digit in the version is only used for minor releases that doesn't change the api and plugin loading will be allowed between for example 1.6.0 and 1.6.2, but not between 1.6.0 and 1.7.0.

erijo commented 13 years ago

In general I like it, but I think that the public headers export/does too much. I would prefer if the classes that looks like interfaces (e.g. plugin.h) were pure interfaces (i.e. only pure virtual methods and no data members).

flynd commented 13 years ago

The intent is for the base classes to be a two-way interface for the plugins and also continue being the interface for manipulating the plugins. If the interface only contains virtual functions then we're almost back to the old way of having the interface for accessing the plugin being separate from the interface used by the plugin.

The private functions are of course a different matter. I would prefer to hide these but I don't know of any why to make an internal sub class and still allowing the plugins to inherit the same base. And I thought a private inner class shouldn't be exposed, not even internally. I'm open to suggestions on different approaches to get around having the private functions there.