D-BUS: Somewhere OBVIOUS, explain _specifically_ why D-BUS vs CORBA, vs. DCE, vs. SOAP, etc.

[David A. Wheeler]

I think a newcomer to D-BUS will not currently find a very
convincing & simple argument for some important questions:
  "WHY should I bother using D-BUS compared to X?",
where X is each of the commonly-known RPC alternatives
like CORBA, DCE, SOAP, etc.

I believe there needs to be a SPECIFIC set of arguments
on why a developer should use D-BUS instead of one of the
other well-known RPC mechanisms, placed where it's easy
to find, to help a developer understand why they should risk
using time to work with D-BUS when there are so many
things to do.  There are sporatic discussions
on the D-BUS mailing list for people to wade through (if they have
infinite time), and generalities (but no specifics) in
the tutorial.  Specific info needs to be somewhere obvious:
a FAQ, the tutorial, wherever. Let me explain why it's needed,
and then give some examples/starting text.

Currently the D-BUS website materials make it look like D-BUS is
"yet another incompatible, nonstandard RPC mechanism"
completely recreated without a real need to do that.
The D-BUS tutorial says what it's designed to do, but not why the various
alternatives already around don't really meet the need.
D-BUS also has a serious non-advantage of being very unfinished
(spec still changing, no reflection, no standard IDL, primitive tools).
There's no info on how to transport it on IP -- I think
many people will want to know that IP transport is AVAILABLE (directly or
through a standard bridge), even if they don't plan to USE it
initially, because they don't want to have to rip stuff out or learn
and use two different mechanisms if they move something off
a machine.

There are already standards (de facto and de jure) that do
inter-app RPC: CORBA, DCE (which has a good implementation recently
released as OSS), DCOM/COM, SOAP, XML-RPC, KDE's DCOP, & more.
There are also a host of other related approaches, like ICE.
I (and many others) are deeply suspicious of any "new"
from-scratch approach when there are several existing
approaches, several of which are standardized.
If it's TRULY not appropriate to use CORBA or DCE,
usually you want to extract out the useful subset instead of
starting from scratch (think of how XML was created from SGML).
The D-BUS work doesn't seem to be doing that.
I think the current text is not sufficiently convincing
to make many want to use D-BUS instead.

Does that mean D-BUS is useless? Not at all.
Actually, I very much respect Havoc Pennington; it
doesn't appear that he's just trying to rebuild stuff
for no reason, and I think there's some expertise here.
Maybe D-BUS really IS needed and will be really useful.
But the current web-available materials don't make a strong case.
It says "what D-BUS is intended for" but not really why
the other alternatives can't be used/tweaked to meet that need.
If nobody can make the case, then that's a serious suggestion that
something is wrong... perhaps this effort should be halted to
switched to whatever exists that cannot be argued against.
And if the case CAN be made, please _document_ it in
a place that people like me can find it... so that they
can see why they'd want to use it.  And I think it'll help you make
sure that D-BUS really does meet the needs you're trying to meet,
by documenting specifically what it does that the others don't.
You'll also help simplify the mailing list -- the question
"why are you reinventing the wheel" keeps coming up,
so if you carefully answer it, you only have to answer it once.

The tutorial tries to make a few handwavey arguments,
but they're too generic.  Why, specifically, should I use
D-BUS instead of CORBA? DCE? SOAP? DCOP? etc.?
Why did you have to start over, instead of defining a subset?
There's been a LOT of work to make CORBA in particular work,
and I hate to see that abandoned (and much redone) unless
it's truly necessary.  I'd LIKE to see there be a standard RPC
mechanism for GNOME, KDE, and whoever else... that it be a SINGLE
mechanism... and for it to reuse existing standards as
much as possible.  If D-BUS is going to be that solution,
then you're going to need to explain WHY.

And actually, it'd be a good idea to figure out how to
create a "bridge" to at least DCE, SOAP, and CORBA.
They're all used, and if you can show how to bridge between
them, then at least you can show that "look, if you use
D-BUS, there's a way to talk with other folks too!"
Basically, your argument is easier if you say
"need X, use this other technology instead; but you
can easily connect these technologies if you need to
by doing Y."

Okay, let me give some specific examples. I give the text below
to the public domain; take them and edit however you like
(though a CREDITS entry of "David A. Wheeler" would be
very appreciated).
Since the tutorial has some "why D-BUS" discussion, I
suggest extending that discussion to give these specifics;
feel free to make it a separate document, or as an
appendix to the tutorial, but make sure
someone viewing the D-BUS website will easily find them.

In "D-BUS applications", add to the list of RPC techniques
DCE and DCOP.  Add to the end list of "distinguish it from
other forms of IPC" the following (which I think are important
but are unstated):
* Implementation can be simple, increasing reliability even when
   the system is under extreme stress, enabling
   use while the system is booting, and enabling use in small-memory
   environments.
* Implementation available for both open source
   (including GPL licensees) and proprietary software without
   royalties or other restrictions.

Then add text like the following (I'm writing down what I _think_
you guys believe; I'm not entirely sure I believe it, so you
need to make your case stronger, including evidence to buttress it):

****

D-BUS was not developed lightly; several other RPC approaches
were used or attempted before D-BUS was developed for these
purposes.  Here's why other approaches don't work for these purposes:

CORBA: At first blush, CORBA appears perfect for this task instead
of D-BUS, but experience has shown otherwise.
GNOME attempted to use CORBA widely in its implementation for years
(through its CORBA ORB, ORBit, and technologies like Bonobo).
KDE also attempted to use CORBA for about a year as well.
People really tried to use CORBA for these applications, however,
few GNOME applications use CORBA today, and KDE abandoned CORBA
for DCOP (described below).  There are many reasons for this.
CORBA is too slow and memory intensive for simple use.
Good CORBA implementations are complex, reducing reliability
and making them harder to use during boot, stress, or constrained
environments. CORBA's C and C++ standard interfaces are far too complex,
creating extreme unnecessary complexity, and many applications
use these languages (OMG is trying to create a
simpler C++ interface).  Ordinary CORBA has
essentially no authentication, and "CORBA security" is so complex
that almost no one implements it, and it's so hard to use that it's
hard to have confidence in it.  D-BUS borrows many ideas
from CORBA; a D-BUS bus is like a CORBA domain, and D-BUS objects
are like CORBA objects. D-BUS supports method calls with
in, inout, and out values like CORBA, and D-BUS's NO_REPLY_EXPECTED
is like CORBA's "oneway" calls.

{I'd like to see more justification on why CORBA is perceived
to be too large/slow.  Is this really just a problem with
poor implementation?  If not, what about CORBA makes it this way?
MAKE YOUR CASE.  CORBA in particular has lots of big-organization
support; that doesn't make it good, but it DOES mean that you need
to clearly show why you plan to abandon it for something else.}

XML-RPC and SOAP: XML-RPC and SOAP impose a great deal of
overhead that is unnecessary and interferes with its intended use.
XML-RPC and SOAP require that all messages be wrapped in
complex XML wrappers, and all data translated into text formats,
all of which has to be undone at the receiving end.
All of this translating back and forth is unnecessary and
inefficient inside a single system, and in particular interferes
with system bus use during boot (where simplicity of run-time
implementation is important, since more complex mechanisms increase
the likelihood of problems and make it hard to fit in limited space).
Also, D-BUS supports bi-directional messages and messages to
multiple destinations via busses.

COM/DCOM: COM/DCOM is widely used in older versions of
Microsoft Windows, but it was not designed to be used on
non-Windows systems.  The COM interface is notoriously hard to
use, and fragile as well; for example, it uses reference counting,
making it easy for minor problems in one application to cause
problems in other applications.

DCE: DCE has many capabilities to support large-scale distributed
communication between systems, including timing services and other
related capabilities.  However, these features cause its implementation
to be large and complex, and it's completely overkill when dealing
with communication that's almost entirely local to a single machine.
This complexity causes problems when trying to perform far more
localized communication, e.g., applications on a desktop.
It's also designed for point-to-point communication, while often
what's wanted in D-BUS's intended environment
is a broadcast capability (e.g., a "bus").
Another problem is that D-BUS is trying to create a setup that
will enable GNOME and KDE applications to work together;
KDE is already using DCOP, so KDE will only switch to something
similar to DCOP, and DCE isn't very similar to DCOP.
{DCE has now been released as open source software by the Open Group
(http://www.opengroup.org/comm/press/05-01-12.htm),
and some argue it's of great value, e.g.,
  http://advogato.org/article/817.html
so if you're going to work so hard to use something else,
you need to explain clearly WHY.  Some potential sources of info:
http://lists.freedesktop.org/pipermail/dbus/2004-June/001243.html
I know DCE supports point-to-point, but I'm not sure it supports
multipoint and async comm; if not, that's a fair criticism, but you
need to DOCUMENT that.  DCE is actually quite capable; if you
believe its implementation is too complex and that causes problems,
explain why!}

Internet Communications Engine (ICE):
(Warning: there's more than one RPC mechanism called "ICE").
The Internet Communications Engine is available and
described at "http://www.zeroc.com/ice.html".
It's available as GPL or as proprietary (requiring royalty) license.
However, this licensing arrangement reduces
the likelihood of widespread adoption by proprietary
software developers, which will inhibit adoption in general
as a general solution.  ICE does far more, e.g., it describes
persistent data.

DCOP: DCOP is an RPC mechanism designed by KDE for its use.
However, it depends on Qt, which causes some drawbacks for
some desirable uses.  Qt dependence makes it less suitable for
boot-time operation and unsuitable for environments where Qt
is not available (e.g., GNOME-only or no-GUI environments, which
could still use a lightweight RPC mechanism for systemwide messages).
Qt dependence also imposes royalty payment requirements on
proprietary programs, even if they're not using Qt otherwise;
it's perceived that this will impede acceptance of the mechanism.
GNOME applications will not want to adopt a mechanism that is
dependent on Qt, and it is highly desirable to create a single
mechanism that both GNOME and KDE applications will use so that
interoperation between such applications is seamless.
D-BUS borrows many ideas from DCOP, while being reimplemented
in a way that eliminates such dependencies, so that anyone
can use it. Many KDE developers view D-BUS favorably; see
"http://cvs-digest.org/index.php?newissue=oct82004".

Sun ONC/RPC: ???

{Again, I've written down what I think are your objections;
please correct them to what you really think and why}

Anyway, I've raised my objection, and presented a
documentation "patch" that I hope will help start fix it.
Is a D-BUS developer willing to place documentation like
this somewhere so that it will be available to others?

Thanks so much, and in particular thanks for wading
through this!  I wish you the very best.

--- David A. Wheeler