From The Linux Foundation

Adding DBus can potentially involve many issues.

There's no real argument about putting the dbus library itself in the LSB.

But lots of other questions: various bindings, such as Qt, Glib, etc.

And how about the internal message passing - is there material there that needs to be standardized?

Bindings

• libdbus-glib.
• libQtDbus.

Input from John Palmieri

From an email conversation with John Palmieri, one of the D-Bus people:

> We want the LSB DBus spec to be something an ISV can count on being 
> there everywhere and for the long haul.  We know that we're going to 
> have to specify at least some of the ABIs, and we have a vague idea that 
> we might need to do more than that.  Do we specify the wire protocols?

Yes the 1.0.x wire protocol is ABI stable.  I think 1.2.x won't have any
changes there either.

> Do we require a daemon?  

System and session bus daemons are the norm and should be expected to
exist.

> Command-line utilities?

dbus-watch and dbus-send

> How should we write 
> our tests; should we require a working DBus daemon, or start our own?

You should require one.  We already have a bindings test suite which can
be used to test compliance at least as a start:

http://gitweb.freedesktop.org/?p=dbus/dbus-test.git;a=summary

4.0 Status

The idea with 4.0 is to target what's shipping now in the major distros. In this regard, SLES 10 is shipping D-Bus 0.6, and RHEL 5 is shipping D-Bus 0.7. The real ABI-stable and wire-stable D-Bus is 1.0, and there's real skepticism about standardizing anything less.

There are a few options:

• Postpone D-Bus until after 4.0; possibly to the 5.0 that's been floated for release in 2009.
• Add D-Bus 1.0, but as a trial-use module.
• Add only the 0.6 D-Bus APIs and protocols that are compatible with 1.0 as well. This may not be feasible if there were major wire protocol changes, or if the ABI changed in a way that can't be reconciled.