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?
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
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.