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

[Julien Puydt <jpuydt free fr>]

Jan Schampera a écrit :
> 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

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:
> - GM_PLUGIN_TYPE_UI
> - GM_PLUGIN_TYPE_VIDEODEV
> - GM_PLUGIN_TYPE_AUDIODEV
> - GM_PLUGIN_TYPE_VIDEOCODEC
> - GM_PLUGIN_TYPE_AUDIOCODEC

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:
> - GM_PLUGIN_FLAGS_PERSISTENT

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

Snark