GNOME and dbus (was Re: C convenience lib (was Re: Is dbus_pending_call_set_notify() thread safe?))
hp at redhat.com
Thu Aug 2 15:38:20 PDT 2007
Havoc Pennington wrote:
> As I also said in that GUADEC mail, for C apps, I think apps are
> suffering most from lack of high-level API to do things like
> introspection, single-instance, tracking bus names, and matching
> signals, so we probably should think about that in addition to tweaking
> libdbus to death and/or reimplementing parts of it...
Incidentally, for C apps I think it's hard to overemphasize this point.
There's quite a large problem with the overall GNOME desktop's use of dbus.
If I had more time to devote, I think I would in order:
1) offer enough additional API so that all the apps currently using
raw libdbus at least get introspection and signal matching and
single instance and tracking who is using your service and so forth
2) figure out how to make GTK loosely (e.g. runtime-optional)
depend on dbus, so stuff like libunique and libnotify can
be placed in a sane location in the platform
3) get the Windows port finished up (which may help with 2)...)
From a GNOME standpoint, the first two would be *huge* and make a giant
difference, allowing the entire platform to finally be sanely put
together instead of jumping through
this-can't-be-in-gtk-due-to-dependencies hoops. Also it would greatly
cut down on the lines of dbus-related code in C apps and libraries.
Much less code and more coherent platform = more efficiency, less bugs
Entirely wrapping libdbus in an object system mapping was probably the
wrong place to start with GLib bindings; ultimately if apps have to
unpack a DBusMessage it isn't a big deal, that isn't the "hard part"
about IPC, and doesn't address the other purposes of dbus such as
tracking the lifecycle of both one's own app and the apps you are
More information about the dbus