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

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

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

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


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