Re: D-BUS [was: Re: Shipping Vera with 2.4]

[Federico Mena Quintero <federico ximian com>]

On Thu, 2003-02-27 at 13:32, Havoc Pennington wrote:

> > Umm, congratulations, you just reinvented {CORBA, SOAP, UNO, COM}.
> 
> Do you seriously think I don't know what these are or haven't
> considered whether they would work and what the tradeoffs would be?

Of course I don't think so; I actually expect it to be the case that you
considered all of these and you would thus know the huge effort that it
takes to create something similar.

> > The idea of having system/user/app muxes is great, but why create a
> > new protocol for sending stuff between them?  We could have a mux
> > that talks an existing protocol and forwards stuff appropriately.
> 
> Again, it's pointless to discuss this until people read archives
> and/or we post a long initial analysis of the topic as a starting
> point.

I have read the list archives; the two important "big picture" mails are
these:

https://listman.redhat.com/pipermail/message-bus-list/2002-November/000004.html
https://listman.redhat.com/pipermail/message-bus-list/2003-January/000044.html

The first one is about "we want D-BUS to do this" and the second one
dives into the architecture, and explains more goals.

I don't think CORBA is the One True Way to do things; however, we have a
very stable implementation thereof *and* all the activation,
client/ambient properties, all the surrounding machinery that is hard to
get right.  I do think that making yet-another on-the-wire
implementation is a waste of time.  You may as well send GIOP around if
you want binary chunks of data --- as far as I can tell from the spec
and from those mails, that is the only reason why you chose a binary
representation rather than something easily parsable like XML chunks.

[I don't think XML is the right way, either, but you get my point.]

I do think that things will be easier to scale in the future if you
choose a structured, textual representation like XML or plain sexps or
whatever.  If you decide to add fields to a certain type of message, it
will be easier for old applications to remain compatible with the new
set of fields... say your first implementation of notifications about a
digital camera being plugged only gives you the device name and the
camera brand/model; applications may find this useful enough.  But if in
a later version you add a field for "lens type that is mounted on the
camera", old applications can just ignore that field (easy to do with
XML crap) while new ones may find a use for it.  Now this may not be
your actual scenario, but it's just an example.

The mail from November also mentions namespaces and a central registry. 
XML gives you the former; generic CORBA plus bonobo-activation give you
both.

In any case, you are not going to be able to make all projects happy. 
As the documents describe it, the line between a message bus and a
component or object IPC system is very blury.  In the end you may want
to write glue for each component system so that it is palatable to each
particular project --- so that you don't introduce a new API and just
can just use the existing one.

We have been preaching, "protocols are hard, don't design your own if
you can avoid it" for ages now.  The D-BUS protocol just looks ad-hoc to
me, and please understand that by this I don't mean to be insulting to
the people that are working on it.

  Federico