[Ekiga-devel-list] [RFC] Plugin metadata

[Jan Schampera <jan schampera web de>]

Hi devs!

The current plugin metadata definition is as follows:

/----------------------------------
| typedef struct _GmPluginInfo GmPluginInfo;
|
| #define GM_PLUGIN_VERSION 0
|
| struct _GmPluginInfo
| {
|   guint version;
|   gboolean (*init) (GmServices *);
| };
\----------------------------------

That raises several problems, probably not now, but maybe in future:


1. Plugin identification for users
Currently the plugin system is designed to automatically load all
plugins in a specific directory. This behaviour works, but may not be
user-friendly (which can be discussed elsewhere, this mail is only
about the technical base specifications).

It makes sense to provide information for human beings to identify the
plugin, containing things like:
- plugin name
- technical plugin name (ID string)
- compile date
- author's name
- probably license
- some short descriptive words
- some bigger help text


2. Plugin functions called by the main hosting program
As of today, the plugin is loaded, and the initializer-function that is
found in the plugin's metadata structure is called. That means, even if
technically possible, the plugin can never be removed because it can
never be cleanly deinitialized.

I suggest to add an internal deinitializer function that enables the
plugin code to remove all eventual bindings into the main hosting
program and free its allocated memory. This function should be called
in case of an unload request before the actual unload.


3. Plugin type
To enable the user interface (in future) to give a categorized
selection of the available plugins, it's necessary that the plugin
provides the own type.

I thought of the following enum:
- GM_PLUGIN_TYPE_UI
- GM_PLUGIN_TYPE_VIDEODEV
- GM_PLUGIN_TYPE_AUDIODEV
- GM_PLUGIN_TYPE_VIDEOCODEC
- GM_PLUGIN_TYPE_AUDIOCODEC


4. Plugin dependencies
The direct internal dependencies can be handled by the plugin's init(),
of course. But it might be wise to inform at least the plugin loader
(and the user) on which other plugins a plugin might depend.

I thought about a GSList or similar of plugin ID strings (as mentioned
in 1.).

The plugin loader could take care to not load plugins with unresolved
dependencies (or it automatically tries to load the dependencies).


5. Plugin flags
A plugin should at least have the control if it can be unloaded or not.
That was the initial idea for the flags. Others are possible, too, but
for now just a:
- GM_PLUGIN_FLAGS_PERSISTENT


Please comment!


Regards,
Jan *TheBonsai* Schampera

-- 
I know life sometimes can get tough! and I know life sometimes can be a
drag! But people, we have been given a gift, we have been given a road
And that roads name is... rock and roll!
KISS in "God gave Rock'n'Roll to you"