Re: Plugin System

[Martin Sevior <msevior seviorpc ph unimelb edu au>]

On Wed, 2003-09-24 at 15:10, Bob Smith wrote:

> So, unless I hear a better argument, the design should assume that
> plugins are app specific. If you want shared functionality, it should be
> implemented as a shared library, and used by your plugin. Also, there
> may be plugins that are used by the plugin system to extend itself.
> These will be global in nature.
> 
> Comments?

I think it makes sense to have common scheme for the XML description of
the plugin.

My idea is that for every plugin.so, there also exists a plugin.xml.
Upon startup every plugin.xml discovered in the appropriate directory is
parsed. It's used to create the menu items/toolbars and or information
that a particular service exists. Plugins do not need to create menu
items or toolbars and the XML description should allow this.

Thinking from the AbiWord experience again plugins provide either an
extra feature accessible from one or more menus or toolbars or they
allow additional file formats to be loaded and saved.

The XML format should specify whether plugin should be immediately
loaded or whether it can be delayed till later.

In the case of additional menu items, the plugin need only be loaded if
the user clicks on the menu item. The XML file contains the text and
icons needed for menu/toolbar.

In the case of document exporters, the plugin need only be loaded if the
user asks to export to that format. The XML file contains the filter
type available for export (so it appears as an option to the user).

In the case of importers, we may only need to load the "importer
sniffer" to determine if the document presented matches the importer.

I think we can come up with a single XML format that is general enough
for all our uses without placing extra burden on developers to
understand things they do not need to. Having a single format will help
translators and hackers moving between the different applications.

Martin