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

[Jan Schampera <jan schampera web de>]

On Tue, 13 Mar 2007 21:43:18 +0100
Julien Puydt <jpuydt free fr> wrote:

> > 1. Plugin identification for users
> > [...]

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

It was meant for an interactive loader system from the preferences,
then users need to know a bit more than the filename IMHO.
Future scenarios, you know ;)

> > 2. Plugin functions called by the main hosting program
> > [...]

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

It doesn't mean it has full control over everything, it only means you
can leave it up to the plugin to clean its own memory and bindings
before it is removed. The bindings shouldn't matter, as they are
one-way, but the allocated memory means a leak, who should free it, if
not the plugin itself (which allocated it and holds pointers to it)?


> > 3. Plugin type
> > [...]

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

It was again more meant for interactive loading, the type doesn't have
a technical reason. Well, there is one scenario where that could matter:
Not all plugins loaded at the same time, but distributed over the
initialization process of Ekiga. Means, load GUI plugins directly after
GUI was initialized, load codec plugins after the devices were
detected, etc... (that would require an extended *_plugins() API of
course, to respect the given type or "any").


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

Yes. It was a not-ready fast shoot. External dependencies are not
affected, of course, for internal dependencies we have our GmServices.

 
> > 5. Plugin flags
> > - GM_PLUGIN_FLAGS_PERSISTENT

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

You can't unload a plugin when it's not designed to be unloaded (or
technically impossible for other reasons). That flag should signal such
a condition to the plugin management system (that refuses to unload it).
A variation of it: A possible deinit() or unload() function that's a
boolean. The plugin could just refuse to let the unload happen (and it
would be wise to not force it in such a situation).


Regards,
Jan

-- 
Once you've got the perfect hammer, everything looks like a nail.