[Telepathy] Uniqueness of objects

Simon McVittie simon.mcvittie at collabora.co.uk
Wed Oct 1 05:28:57 PDT 2008

On Wed, 01 Oct 2008 at 11:32:56 +0300, mikhail.zabaluev at nokia.com wrote:
> >-----Original Message-----
> >From: telepathy-bounces at lists.freedesktop.org 
> >[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
> >ext Simon McVittie
> >Hmm... but thinking about it, even if we refcount handles in 
> >telepathy-glib,
> >this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a
> >connection, since neither library will be willing to call into 
> >(= depend on)
> >the other in order to update the shared handle cache :-( Any ideas?
> Don't do that, then?
> If any process happens to use two Telepathy client stacks at the same time, it's an architectural horror, isn't it?

It is. However, each stack can't necessarily know that the other exists,
in the presence of a plugin architecture loading arbitrary misc into a
process (pathological case: two "Telepathy-enabling" plugins are loaded into
Firefox, one of which uses GLib and one of which uses Qt).

The D-Bus library APIs, and the author of D-Bus, encourage even
different stacks (GLib vs Qt vs raw libdbus) to share a DBusConnection
(and hence a unique name). I believe dbus-glib and QDBus are in fact the
only major bindings that do this connection sharing (dbus-python did
once, but it turns out that preventing it from asserting basically
requires it to have its own connection, so now it does).

It might be reasonable for us to declare that we don't support this case -
after all, we don't currently support using telepathy-glib from multiple
threads either - but I can't see any way to enforce it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20081001/d711de32/attachment-0001.pgp 

More information about the Telepathy mailing list