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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #6 from Olli Salli <ollisal at gmail.com> 2012-01-12 01:39:09 UTC ---
(In reply to comment #5)
> I had a discussion with Oggis on irc about this, it's not really easy to factor
> out gabble_connection_get_type() into
> different files.  And currently the connection is a property of the plugins  So

Yeah, the plugins currently get passed a GabbleConnection instance in the
create_sidecar_async function, and the sidecars generally take a reference to
it so that they can call these functions:

http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/gabble/connection.h

This is not the full GabbleConnection API. However, it's still a sizeable part.

The core of the problem is that the gabble_connection_get_type() implementation
which expands out of the G_DEFINE_TYPE_WITH_CODE invocation needs to reference
all the interface init symbols for all interfaces GabbleConnection implements.
And these in turn recursively depend on most everything in Gabble, so if we
pull the current gabble_connection_get_type() into the plugin DLL, we have to
pull in about everything else as well.

> oggis proposed that it could be solved by having a GabbleSidecarManager which
> will hand over the GabbleConnections to plugins and there wouldn't be a
> gabble/connection.h with the update_sidecar_capabilities, add_sidecar_own_caps
> functions, but some gabble/sidecar-manager.h declaring those

No sorry, I dunno if I've explained this unclearly. They can't hand over a
GabbleConnection; if we want to do any GObject type sanity checks at all, we
need the gabble_connection_get_type() definition.

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. Then plugins would only
refer to a GabbleSidecarManager and a TpBaseConnection, and we could drop at
least most of the GInterface implementation dependencies out from the plugin
lib.

But is this practical? I see from connection.h that this will anyway bring in
to the sidecar manager object at least the caps cache in addition to the Wocky
context and local identity which are basically unavoidable. Of course, we could
play some further dependency inversion tricks to cut even those out.

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. Of
course, the sidecar manager object could relay the signals, but we have to
define which GabbleConnection signals are part of the plugin API and which
aren't etc for this.

Of course, being plugin accessible API of GabbleConnection, all those caps
cache things etc need to be in the plugin lib whether they're a part of
GabbleConnection or some smaller object hanging off it.

> 
> Any comments or idea's about this approach ?  We are also wondering if there
> any other workaround which we can do without needing to change the plugin API
> again .

Anything which would enable a compatible definition of GABBLE_TYPE_CONNECTION
without pulling in as dependencies all the GInterface implementations from the
G_DEFINE_TYPE_WITH_CODE invocation would do.

A dirty hack idea:

* define a global GType variable in the plugin lib
* make some GabbleConnection construction function which is always called
before  plugins are given the GabbleConnection set that variable to the real
return value of gabble_connection_get_type()
* define GABBLE_TYPE_CONNECTION to read that variable in plugins
* ... but leave it really calling gabble_connection_get_type() for the gabble
internals, so that the basic things like g_object_new work in the first place.

Ugghhh....

If we just can't work anything out, we have to pretty much just turn the former
gabble-convenience library as a whole into a gabble-plugins library. But that'd
be extremely shit because as a DLLs, its ordinals would change basically every
second and your plugins would just fail, fail, fail to runtime link to it and
would require a relink at least every gabble release.

Sorry, DLLs are utter crappy troublemakers compared to .so's. (But they're fast
at runtime, essentially always prelinked, woo...)

Ideas welcome,
Olli
The GObject noob

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