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


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.


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