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

Jan Schampera a écrit :
Hi devs!

The current plugin metadata definition is as follows:

| typedef struct _GmPluginInfo GmPluginInfo;
| 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

The point is that normal people shouldn't look at the plugins ;-)

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.

Well, that would mean the plugin has full control over everything related to it... which is a strong assumption! I decided it was too complex to do reliably.

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:

Too restrictive ; hence the no-type. But a GmService object which still allow things to find their place.

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).

Well, I thought each plugin would be best placed to decide things, especially since a plugin could decide to load or not depending on external things (like : detect there's a codec installed on the system, hence load to make use of it -- if not, don't load).

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:

Same problem as with unloading : it assumes the plugin has full control.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]