[Bug 44649] Gabble plugin API symbols should be factored out to a separate library

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jan 12 12:38:55 CET 2012


https://bugs.freedesktop.org/show_bug.cgi?id=44649

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-01-12 03:38:55 PST ---
(In reply to comment #6)
> Thus my idea: split out exactly those parts required by the gabble/connection.h
> API from GabbleConnection to a separate object. This could be something like
> GabbleSidecarManager, better name suggestions welcome.

... or to a GInterface that GabbleConnection would implement.

In Mission Control, the plugin API is entirely in terms of GInterfaces, evenly
divided between "implement this in your plugin" and "only implement this in
MC"; then MC contains exactly one implementation of each "implement this in MC"
interface. This might be overkill, but it keeps the plugins library really
small.

> However, even without that this is still a big change... the plugins are quite
> tied to GabbleConnection details - some even connect to its GObject signals.

My opinion would tend to be "ceci n'est pas un plugin API" but you know what
I'm like about stable API guarantees ;-)

(Gabble's plugin ABI can't really be considered stable anyway, until Wocky is a
real shared library with a SONAME, since plugins are allowed and encouraged to
use Wocky.)

(In reply to comment #7)
> an alternative for our Ytstenut purposes could be just
> admitting the plugin API does not exist on Windows, and instead merging the
> Ytstenut service discovery and channel code directly to Gabble

I'd feel happier about this if it was structured somewhat like a plugin, with
only the linking/initialization being different.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.



More information about the telepathy-bugs mailing list