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

[Julien PUYDT <jpuydt free fr>]

Hi,

as I'm working on the new addressbook code, a problem becomes more present :
- the avahi addressbook depends on avahi ;
- the evolution addressbooks depend on evolution-data-server ;
- the kde addressbooks (yes, �ic Bischoff is working on this :-) ) 
depend on some kde libs ;
and while we can clearly make sure anybody can choose his dependancies 
with --disable-foo and --enable-bar switches, there is still the problem 
of distributions. They won't enable everything. They can't ship a 
package for each combination of options!
An obvious solution to that is a system of plugins : distributions will 
be able to ship ekiga-eds, ekiga-kab, ekiga-avahi, ekiga-whatever, which 
the user will be able to choose depending on the preferences.
Now, this is all nice, but how will that work?

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.
I have no code at all at this point ; merely questions... comments, 
ideas and warnings are welcome.
Snark