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

[Julien Puydt <jpuydt free fr>]

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

My idea was that the plugin would be loaded anyway, but only become 
active when the user clicks something in a list, because the plugin 
would have registered itself to such a list -- with all data we want ;-)

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

If your plugin creates new type of GObject, it comes with code for these 
GObjects. If another part of the code uses one such object, you unload 
the plugin, and this GObject calls a function which now isn't there 
anymore...

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

I would better see a service, where plugins register themselves to get 
enabled (and possibly disabled afterwards, but the code still sitting in 
memory for already existing objects).

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

Well, having two levels of dependancy resolution (one in the plugin 
loaded and another in each plugin) doesn't look nice, so I pushed 
everything in the plugins.


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

I would make plugins allow/disallow *inactivation* but not *unloading*.

Snark