Re: [Ekiga-devel-list] [WIND] Plugins in ekiga

[Julien PUYDT <jpuydt free fr>]

Julien PUYDT a �it :
> As a rough sketch, I would say things will go like this :
> - a plugin will export a function, say gm_plugin_descriptor, which will 
> return a GmPluginInfo structure ;
> - upon startup, ekiga will load the plugins (in a known directory), and 
> use the GmPluginInfo of each.
>
> So what do we put in the GmPluginInfo structure? First of all, I would 
> say we put a version, so we only load the plugins we can support 
> (reusing the D-Bus component versions may not be stupid here).
>
> We also put in there an initialisation function, which will probably 
> return a gboolean, so we know if we can keep the plugin or dump it.
>
> What is trickier is : what do we give to this function ? If we want to 
> make future extensions easy, we should probably give it a GmServices 
> structure.
>
> I don't know exactly what to put in this structure :
> - probably we will want a plugin to be able to start/stop/pause/whatever 
> calls ;
> - certainly we will want a plugin to be able to hook itself to the 
> addressbook code, since it's one of the incentives.

Here is another point to take into account : dependencies.

For example, it would be nice to have a kde-core plugin, which would 
setup things for kde integration, which the kde-addressbook plugin would 
use -- or any other kde-related plugin.

Another example would perhaps be a dbus-core plugin, on which various 
dbus plugins would depend.

I still need to think about it some more.

Any insight ?

Snark