D-BUS background

[Havoc Pennington <hp redhat com>]

Hi,

More details on D-BUS.


Basics
===

D-BUS was started end of November after a conference call with some
core KDE developers, and code was first posted after Christmas:
https://listman.redhat.com/pipermail/xdg-list/2003-January/001109.html

You can find the latest info/downloads here:
http://www.freedesktop.org/software/dbus/

Tarball release is a week or two behind CVS, but the source code in
the online documentation is up-to-date as of tonight.

message-bus-list archives are probably helpful too:
https://listman.redhat.com/pipermail/message-bus-list/


Technical Overview
===

D-BUS has two layers. One layer could be described as "libICE that
sucks less"; it is a way to establish and authenticate network
connections, and then exchange messages over them. This layer is
peer-to-peer (one-to-one communication).  Messages are headers (with
message name, length etc.) then a list of data arguments (string, int,
etc.). There are no composite data types now, but perhaps
lists/collections or "custom named types" should be added.

The second layer is the message bus, which is a peer that lots of
applications can connect to. The message bus is simply a router, it
forwards messages between applications according to which messages
apps have signed up to see. The bus gives apps the ability to
broadcast messages, and do simple IPC without creating a dedicated
peer-to-peer socket.

The peer-to-peer layer is probably 70% done right now, the message bus
layer maybe 30%.

The message bus is intended to have a configuration file which
determines what address it will listen on, what permissions connected
applications will have, where to find services to activate, and this
sort of thing. With one configuration file, the message bus will
become a systemwide daemon that's used to broadcast system events,
such as "low disk space" or "camera plugged in." With another, it will
be a per-login-session message bus. That's the current plan anyway,
not implemented.


Who is working on it
===

The immediate hacking on D-BUS is:

 - we want to try using it in systemwide mode for Red Hat Linux (and
   encourage other OS vendors to do same if it works out well)

 - Anders is trying to make GConf work with it for a CodeFactory
   project

 - KDE developers are thinking about it as a DCOP replacement
   in KDE 4 timeframe

On the GConf thing: my opinion is that this can't be finished in time
for GNOME 2.4, and that "enterprise GConf features" are higher
priority, but I do think a D-BUS based interface to the config system
is useful.


CORBA, DCOP, SOAP, UNO, COM, Bonobo, GObject, QObject, XPCOM,
KParts, Mono, XML-RPC
===

The above list of software may be taken as similar to D-BUS to one
extent or another.

The above list mashes together three kinds of thing:

 a) runtime/component systems
 b) IPC systems
 c) GUI control/widget embedding (built on a) typically)

Most casual observers don't seem to understand the differences here;
for example they think Bonobo is only c) or think DCOP is an example
of a).

D-BUS is only in the b) category and has little to do with a) or c).
Its unique features as an instance of b) are the message bus with
broadcast/activation capabilities, and a low-round-trips low-bandwidth
binary protocol.

The final D-BUS spec will be longer than the one for XML-RPC, but
shorter than the specs for most of the other things listed there.
i.e. D-BUS is relatively not featureful.

D-BUS is however a fair bit more complex than DCOP, which has been
adequate for a lot of useful stuff in KDE.


Bonobo
===

Does D-BUS replace Bonobo? Not really, because it doesn't do a) or c)
and Bonobo does. However, I think D-BUS will be better for b)
*in most cases*. Here's why:

 - it does not reenter the main loop unexpectedly

 - it has reliable and easy-to-use means of handling service
   lifecycles

 - you can do efficient broadcasts

 - it's a small, unambitious library/protocol that requires little
   buy-in

 - it's shared with other desktop environments and applications

 - it can also be used for the systemwide bus

These are not IMHO "theoretical beauty" kinds of issues, rather they
are practical issues that have a lot of end user impact in terms of
increased stability and integration.

I don't expect anyone to believe on faith that D-BUS is better in
these areas (or "better enough" to be worth changing). The code is out
there, people will try it out, they will make up their minds.

There are a significant number of core GNOME developers that seem to
be unhappy with Bonobo as an IPC solution. I know of (but won't name,
as I don't know if the maintainers would appreciate it) at least four
large, core, GNOME applications that tried out-of-process Bonobo on a
significant scale and are unhappy about how it turned out in
practice. Moving code off of Bonobo is done silently though, because
people don't want to start flamewars. That's my job. ;-) I believe at
some point we have to be honest about the real experiences of core
developers. I'm sure some core developers have had good experiences,
don't get me wrong. Everyone will probably chime in here.

So far most people have been quiet about their Bonobo opinions in
public, maybe because they don't want to get flamed, or they don't
want to return to the bad old days of endless devel platform flamewar
hell. But that is no way to make technical decisions. At some point we
have to fix the issues.


What about Bonobo in contexts a) and c)? Well, I'm not a big fan of it
as everyone knows, I would prefer something along the lines of UNO or
Mono if we had it. But in-process Bonobo works fine for the future
that's near enough to be worth thinking about, and maybe it will
evolve over time so who knows. It's kind of beside the point for now.

Here is a more abstract discussion of "what if":
  https://listman.redhat.com/pipermail/message-bus-list/2003-January/000044.html

However, I believe D-BUS makes sense on its own merits for b),
wherever we go on the component/runtime system and widget embedding.


IIOP
===

Federico's question: regardless of Bonobo, should D-BUS use the CORBA
wire protocol?

The D-BUS protocol is custom-designed for a message bus and the
semantics that we want the client library to have. I'm not sure IIOP
would work; square peg, round hole. D-BUS doesn't have CORBA
semantics. Plus the D-BUS protocol is easy to implement, and already
implemented.

It's not like you can interoperate with other ORBs when D-BUS doesn't
implement the whole CORBA spec; D-BUS would definitely be an IIOP
subset, or an almost-but-not-quite compliant IIOP implementation, 
which isn't really useful.

But maybe a more detailed analysis/code/use-cases would show this to
be a good idea.


Long-term view
===

In the long term, if we want an IPC system that is used *via* the
runtime/component system, it really does not matter what wire protocol
or IPC implementation we use now. Because it's trivial to proxy an
introspectable component system over as many protocols as you want.

That's why my view on D-BUS is that it should err on the side of
something we can get implemented and up and running soon.  If we
eventually have the ubercool component system - based on Bonobo, or
something else - then great, we can then proxy it over IIOP, D-BUS,
SOAP, and morse code. But until we have the all-encompassing
super-duper system, we may as well KISS.


GNOME Roadmap
===

First off, I don't think changing our solutions for a) and c) is an
issue for now. It's big and hard and not worth thinking about any
concrete actions in that area for a while.

I would advocate looking at D-BUS as a systemwide message bus in GNOME
2.4-ish timeframe, and *maybe* also consider it for one or two
trivial/peripheral sample uses in that time, depending on how the
project goes. I also expect some ongoing unstable/prototype code to
try using it.

In the GNOME 2.6-ish timeframe, which is also the KDE 4-ish timeframe
I believe, we might consider more heavy reliance on D-BUS if things
have gone well. If KDE adopts D-BUS I think it would be a big mistake
not to at least use it for interoperable specs.

Depending on how things turn out, we may leave the official GNOME
solution as CORBA - and use D-BUS only for some shared specs with KDE,
for broadcasts, and/or for the systemwide bus. The code isn't all
written so time will tell.

I'm not working on D-BUS with the assumption that GNOME will use it; I
need it for the systemwide bus case anyhow.


So, that's it. Try to keep the flames *somewhat* under control.  If
you want to follow D-BUS on an ongoing basis, please join
message-bus-list.

Havoc