Havoc's Blog

John
is threatening to roll the D-Bus low-level
API 1.0
tarball in a couple of days. I just looked back in the ChangeLog:

2002-11-21  Havoc Pennington  <hp@redhat.com>
	* Initial module creation

Coming right up on year 4. Now that’s what I call a conservative
release schedule! The last big API change I believe was:

2005-01-15  Havoc Pennington  <hp@redhat.com>
	* Land the new message args API and type system.
	This patch is huge, but the public API change is not 
	really large. The set of D-BUS types has changed somewhat, 
	and the arg "getters" are more geared toward language bindings;
	they don't make a copy, etc.
	There are also some known issues. See these emails for details
	on this huge patch:
	http://lists.freedesktop.org/archives/dbus/2004-December/001836.html
        http://lists.freedesktop.org/archives/dbus/2005-January/001922.html

Software sure does take forever, in this case double-forever. D-Bus
has rarely been anyone’s full-time job, and there were several
stretches with essentially no work happening.

What’s the significance of the D-Bus release? Well, the original D-Bus
goal was a “system message bus”, to support things like HAL. A secondary
but hoped-for goal was to replace CORBA and DCOP with a
simple desktop-independent IPC system. Both seem to be working out pretty
well these days.

A lot of work remains though. Here are some of the major items:

Bindings, bindings, bindings. The low-level
libdbus does not
need to be growing many new features or much new code at all over the
next couple years, but there’s still all kinds of room to improve on
the high-level bindings as most of them remain pretty immature.

The GLib bindings could be a lot easier to use. The original
intent was to have no “IDL” xml file to mess with, but nobody has
implemented the C parser (could be based on gtk-doc) or GLib
introspection to avoid it. There’s AFAIK no roadmap for what should be
involved in getting these bindings to 1.0, and I’m sure the bindings
could be improved many small ways.

Bindings are essential. The low-level API is both easy to misuse and
kind of a pain in the ass.

Performance. I’ve noticed that people are profiling
GTK-on-Cairo well after its release, and so far D-Bus is on the same
track, despite some
strong hints. Unlike the UI toolkit, I doubt D-Bus speed is very
user-perceptible, though I do know D-Bus isn’t especially peppy.
Nontheless, I’m sure someone is going to benchmark it vs. other IPC
systems and post shocking graphs, and to them I say, find the hotspots
and send patches already.

Windows port. There’s some work on the Windows port, and I’m
not sure of the status in detail, but I think it could be done in a
week or two of effort. Would like to see someone hammer this out for 1.2.

System activation.
David
Zeuthen’s work to enable the systemwide bus to start daemons will
likely land in a “1.2” sort of release, ideally within a few months.

Tutorial documentation.
The low-level libdbus has almost excruciatingly thorough API
documentation if I do say so myself, but nobody should really be using
that API anyway and API docs are bad for getting started. “Getting
started” documentation is needed for each high-level binding, with examples.

D-Bus Viewer. KDE had a neat tool for DCOP that let you browse
all the running apps and introspect their methods. This is really
useful, and a D-Bus equivalent is needed. There was a start on one in CVS at
one point, but it hadn’t gotten very far.

Integration into the GTK+/GNOME API. Lots of things in GNOME
can be cleaned up and made simpler with D-Bus available. For example,
the bat**** insane lifecycle-management/activation code in
libgconf/gconfd-2 can be nuked. (please save
us – it’s so simple
and things are so
broken.)

For applications that want to be single instance and can just rely on
D-Bus, there’s no need to wait for a fancy “unique application”
library – just try to own your app’s D-Bus name on startup, and exit
anytime you lose the name or fail to become its owner. Presto,
single-instance. (This is what bus names were designed for, btw.)

Alternative transports and X forwarding.
DBUS_SESSION_BUS_ADDRESS should be ssh-forwarded and tunneled, just
like DISPLAY. Until this is done, remote applications won’t really
work right. And the sooner this is done, the sooner a new-enough
version of ssh will get rolled out to distributions.

A somewhat hackier approach would be to implement a libdbus
transport
that worked over an X connection, probably using X properties to
transfer messages.

Please, report API bugs. Especially in the bindings, but it’s
still possible to evolve libdbus via deprecation or extension as
well. Several bad bugs were almost in libdbus 1.0 because people just
assumed they were by design (diabolical design?) and worked around them
instead of saying something or patching the library.

A final fun fact about libdbus 1.0:

$ nm -D dbus/.libs/libdbus-1.so | grep ' T ' | wc -l
200

(This post was originally found at http://log.ometer.com/2006-11.html#6)