Announcing availability of libgdbus

Simon McVittie simon.mcvittie at
Tue Apr 15 14:50:45 PDT 2008

Hash: SHA1

On Tue, 15 Apr 2008 at 16:50:34 -0400, Colin Walters wrote:
> I think all the stakeholders in dbus-glib agree it is fairly
> fundamentally broken from an API standpoint and doesn't have much of a
> future.  Any objections to elevating libgbus to more "official" status
> by having it in the bindings page?

I think that might be a little harsh... dbus-glib needs a lot of cleanup, but
I'm not convinced it should die entirely. I certainly wouldn't be keen
to deprecate it just yet, particularly if its potential replacements
libgbus and hippo-dbus-helper haven't actually had any releases in their
own right.

The TpProxy code in telepathy-glib wraps DBusGProxy and provides a
rather nicer API by working around some of DBusGProxy's deficiencies -
obviously, this could all land in dbus-glib at some point, although
we've been concentrating on prototyping it in telepathy-glib and getting
it working well there. Similarly, we've done some crazy^Winteresting
stuff on the service side by exporting D-Bus APIs using generated
GInterfaces, which I think is the way forward in future.

In the longer term, I think we could make a considerably nicer API
for D-Bus GObjects by making more use of GInterfaces (see, section "Grand Unified

I think the most important thing is to have a D-Bus GSource
library, like the dbus-glib-main library that's been proposed (perhaps best
shipped as an independent library inside dbus-glib tarballs, for now, although
it could get moved without API/ABI changes to some successor of dbus-glib
later), since this is the only part of the dbus + glib glue that needs to be
shared. (Perhaps it needs thread integration etc. too, I don't know). If this
library could also fix I'd
be very happy.

(If this code was written from scratch, or derived from somewhere like
libgbus or avahi, this would have the side benefit that we'd lose some
of the unrelicenseable ex-Code Factory code. Much rejoicing.)

dbus-glib, dbus-python, libgdbus and hippo-dbus-helper could then all
use this main loop integration, meaning that more than one of these
object-model/convenience API layers could be used in the same process
(by different plugins, perhaps) without causing fights over the main loop



More information about the dbus mailing list