Patch: explain specifically differences of D-BUS to alternatives.
David A. Wheeler
dwheeler@dwheeler.com
Sat Jan 22 09:11:13 PST 2005
Attached is a patch to the D-BUS tutorial that explains,
with specificity, why D-BUS was created when there are RPC
alternatives. I'm a big believer in standards & reuse;
if you determine that existing tools won't do the job, I think you
owe it to your potential users to explain WHY you created
an alternative, with _specifics_ that make sense.
Please apply this patch! Almost all the text is in an appendix,
so people who don't want this info will naturally skip it.
But the people who DO want this info will now have
one place to go for the info.
Basically, these are frequently asked questions.
This is my attempt to answer them, using the
material various folks here have posted along with
other info. As Zack Rusin wrote:
> ... I agree that it'd be nice to have some kind of a comparison
> between them all.
Havoc Pennington said:
> Anyhow, in short if someone thinks dbus is a wheel reinvention and they
> want to use CORBA, then they should use CORBA... why shouldn't they? I
> have no idea a priori whether dbus is actually better for whatever they
> are trying to do.
Yes -- but you know LOTS more about D-BUS than they do.
Thus, you can really help them understand the
differences between D-BUS and alternatives so that they can
pick the right tool for the job. It's a pain to
do all that research to understand exactly what the
differences are between D-BUS and some other specific
RPC approach (trust me -- I just did it).
Explaining specific differences between D-BUS
and other well-known approaches is a _real_
help to developers who must make that choice.
Explaining D-BUS in general helps, as you've already done,
but I think specific contrasts will help developers as well.
Please let me know if I've made a mistake; I'll be happy to
make a patch-on-this-patch and maintain this part (this appendix)
of the document, if the Havoc is willing to
accept this patch to the tutorial. If you'd prefer this
to be a separate document instead of being part of the
tutorial, let me know. I just thought it made sense being
with the tutorial, because the tutorial already explains
the problem domain D-BUS is intended for.
--- David A. Wheeler
-------------- next part --------------
--- dbus-tutorial.xml.orig 2005-01-20 22:44:10.000000000 -0500
+++ dbus-tutorial.xml 2005-01-22 12:07:46.000000000 -0500
@@ -65,7 +65,8 @@
</para>
<para>
- libdbus only supports one-to-one connections, just like a raw network
+ The libdbus library
+ only supports one-to-one connections, just like a raw network
socket. However, rather than sending byte streams over the connection, you
send <firstterm>messages</firstterm>. Messages have a header identifying
the kind of message, and a body containing a data payload. libdbus also
@@ -101,12 +102,19 @@
<para>
There are many, many technologies in the world that have "Inter-process
communication" or "networking" in their stated purpose: <ulink
- url="http://www.mbus.org/">MBUS</ulink>, <ulink
url="http://www.omg.org">CORBA</ulink>, <ulink
+ url="http://www.opengroup.org/dce/">DCE</ulink>, <ulink
+ url="http://www.microsoft.com/com/">COM/DCOM</ulink>, <ulink
+ url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP</ulink>, <ulink
url="http://www.xmlrpc.com">XML-RPC</ulink>, <ulink
- url="http://www.w3.org/TR/SOAP/">SOAP</ulink>, and probably hundreds
- more. Each of these is tailored for particular kinds of application.
- D-BUS is designed for two specific cases:
+ url="http://www.w3.org/TR/SOAP/">SOAP</ulink>, <ulink
+ url="http://www.mbus.org/">MBUS</ulink>, <ulink
+ url="http://www.zeroc.com/ice.html">Internet Communications Engine (ICE)</ulink>,
+ and probably hundreds
+ more. Each of these is tailored for particular kinds of application,
+ and while perhaps ideally only one would be necessary, in practice it
+ appears that different ones are needed for different purposes.
+ D-BUS is designed to support two specific cases well:
<itemizedlist>
<listitem>
<para>
@@ -131,6 +139,10 @@
such as CORBA and DCOP. D-BUS is built on that experience and
carefully tailored to meet the needs of these desktop projects
in particular.
+ This does not mean that the other IPC approaches available are
+ useless; it's just that for these particular use cases
+ the D-BUS developers believe there was
+ a need to create something new and specialized for the purpose: D-BUS.
</para>
<para>
The problem solved by the systemwide or communication-with-the-OS case
@@ -165,22 +177,28 @@
D-BUS may happen to be useful for purposes other than the one it was
designed for. Its general properties that distinguish it from
other forms of IPC are:
- <itemizedlist>
+ <orderedlist>
<listitem>
<para>
Binary protocol designed to be used asynchronously
(similar in spirit to the X Window System protocol).
+ This gives it reasonably high performance (by eliminating
+ unnecessary translations), yet it include an "endianness"
+ field so translations between computer architectures can be
+ performed when necessary (and only when necessary).
</para>
</listitem>
<listitem>
<para>
- Stateful, reliable connections held open over time.
+ Stateful, reliable connections held open over time,
+ simplifying programming.
</para>
</listitem>
<listitem>
<para>
The message bus is a daemon, not a "swarm" or
- distributed architecture.
+ distributed architecture. This is easier to understand
+ and is easier to mesh with existing security mechanisms.
</para>
</listitem>
<listitem>
@@ -201,7 +219,68 @@
message bus.
</para>
</listitem>
- </itemizedlist>
+ <listitem>
+ <para>
+ Designed to make debugging easy;
+ each message includes its type information.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Specially tailored to directly address its use cases;
+ thus it better matches the problem
+ and avoids including unnecessary mechanisms.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Designed for simple implementation;
+ increasing reliability when under stress, enabling use
+ while booting (when many mechanisms
+ aren't yet running), and enabling use in small-memory
+ environments.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Interface is easy for all programmers to adopt.
+ Many bindings (including universally-callable C)
+ for various languages and toolkits have been developed,
+ as well as a port to Microsoft Windows.
+ D-BUS doesn't even require using an IDL
+ preprocessor (though you can certainly use one); it has a
+ simple ASCII type specification system that's
+ easy to understand and use directly.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ D-BUS is primarily defined by a wire protocol,
+ not the programming API or an IDL.
+ This means that developers can choose
+ to use an API "native" to their language and toolkit.
+ They can also choose to use alternative APIs if they're more
+ convenient.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Licenses have been selected to make it easy to adopt by all.
+ Useful implementations are available that can used by
+ by both open source software (including GPL'ed software)
+ and proprietary software without royalties or
+ other restrictions.
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ <para>
+ D-BUS was created after several other RPC approaches were
+ considered and determined to be less effective for these
+ two major use cases. See <xref linkend="comparisons"/>
+ for more information about other RPC mechanisms like CORBA,
+ and why D-BUS was created instead (these are frequently asked questions
+ about D-BUS).
</para>
</sect2>
</sect1>
@@ -604,4 +683,296 @@
</para>
</sect1>
+ <sect1 id="comparisons">
+ <title>Comparisons with other RPC mechanisms</title>
+ <para>
+ The following subsections compare D-BUS with some other common RPC
+ mechanisms, and try to explain why D-BUS was created
+ even though these other RPC mechanisms exist.
+ Newcomers to D-BUS frequently ask questions like
+ "why are you reinventing the wheel?", pointing to various
+ pre-existing RPC mechanisms.
+ D-BUS was not developed lightly; many other RPC approaches
+ were used or evaluated before D-BUS was developed.
+ The purpose of these subsections is to save the D-BUS developers
+ from having to re-answering the same question each time, namely,
+ why they aren't using one of the various other available approaches.
+ This doesn't mean D-BUS is perfect; if one of these other
+ approaches meets your needs better, please use it instead, and
+ please don't get into flamefest trying to prove any one is better.
+ And in some cases the best solution may be to use them together;
+ it should be possible to bridge many of these if you desire.
+ </para>
+ <sect2 id="corba">
+ <title>CORBA</title>
+ <para>
+ At first blush,
+ <ulink url="http://www.omg.org">CORBA</ulink>
+ appears perfect for the task of integrating
+ desktop applications.
+ CORBA is designed to support object-oriented RPC between objects,
+ automatically marshalling parameters as necessary, and
+ CORBA continues to be useful for many purposes.
+ CORBA is strongly supported by the
+ <ulink url="http://www.omg.org">Open Management Group (OMG)</ulink>,
+ which produces various standards and supporting documents for CORBA
+ and has the backing of many large organizations.
+ There are many CORBA ORBs available, both proprietary ORBs
+ and Free / open source software ORBs (the latter include
+ <ulink url="http://orbit-resource.sourceforge.net/">ORBit</ulink>,
+ <ulink url="http://www.mico.org/">MICO</ulink>, and
+ <ulink url="http://www.theaceorb.com/">The ACE Orb (TAO)</ulink>).
+ Many organizations continue to use CORBA ORBs for various kinds
+ of RPC.
+ </para>
+ <para>
+ Many years have been spent trying to apply
+ CORBA in desktop environments.
+ GNOME was originally designed specifically to
+ use CORBA widely in its implementation. The GNOME project
+ developed a CORBA ORB tuned for its needs
+ (ORBit) as well as technologies built on CORBA
+ (such as Bonobo), and worked for years trying to use
+ CORBA to build a powerful desktop environment.
+ KDE also attempted to use CORBA for about a year.
+ However, after person-years of effort
+ trying to use CORBA for these purposes, many are now
+ convinced that CORBA is not the right tool for the job
+ of supporting inter-application communication in a desktop.
+ Although great effort has been expended in GNOME,
+ relatively few GNOME applications now use CORBA significantly.
+ KDE eventually abandoned CORBA and switched to its own
+ DCOP (described below).
+ </para>
+ <para>
+ There are many reasons why many believe CORBA
+ does not suit these applications well.
+ CORBA includes a large number of capabilities that are very
+ useful in other circumstances, but those extra capabilities
+ interfere with the specific use cases that D-BUS is designed to meet
+ (single-session desktop IPC and local machine IPC).
+ CORBA's C and C++ standard interfaces are very complex to use;
+ using the CORBA C++ standard interface requires
+ memorizing complex tables to figure out how to handle memory,
+ and cause the basic CORBA types to "leak" all over an application.
+ OMG is trying to create a simpler C++ interface.
+ Ordinary CORBA has
+ essentially no authentication, and the CORBA security
+ extension is so complex that almost no one implements it.
+ CORBA implementations are considered by many GNOME and KDE
+ developers to be too slow and memory intensive for the simple tasks
+ they need to do.
+ Good CORBA implementations are complex, reducing reliability
+ and making them harder to use during boot-time, stressed
+ situations, or in constrained memory environments.
+ </para>
+ <para>
+ D-BUS was developed after using CORBA, so 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.
+ It is probably possible to build a partial CORBA implementation
+ on D-BUS, and to implement a bridge between D-BUS and CORBA,
+ should that be of interest; at this time no one has done so.
+ </para>
+ </sect2>
+ <sect2 id="soap">
+ <title>XML-RPC and SOAP</title>
+ <para>
+ In <ulink url="http://www.w3.org/TR/SOAP/">SOAP</ulink> and
+ <ulink url="http://www.xmlrpc.com">XML-RPC</ulink>,
+ RPC calls are transformed into an XML-based
+ format, then sent over the wire (typically using the HTTP protocol),
+ where they are processed and returned.
+ This can be very useful for communication between different computers.
+ In the long term, it should be easy to create a
+ D-BUS transport variant that could use XML-RPC or SOAP, if
+ it was important to use them.
+ </para>
+ <para>
+ However, XML-RPC and SOAP impose a great deal of
+ overhead that is unnecessary and interferes with simple
+ desktop application and local computer communication.
+ XML-RPC and SOAP require that all messages be wrapped in
+ complex XML wrappers, and all data must be 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. In particular it 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 buses more directly.
+ </para>
+ </sect2>
+ <sect2 id="dce">
+ <title>DCE</title>
+ <para>
+ <ulink url="http://www.opengroup.org/dce/">Distributed Computing Environment (DCE)</ulink> is
+ an industry-standard vendor-neutral standard that includes
+ an RPC mechanism.
+ <ulink url="http://www.opengroup.org/comm/press/05-01-12.htm">The
+ Open Group has released an implementation as
+ open source software</ulink>.
+ DCE is quite capable, and includes a vast amount of functionality
+ including a distributed time service.
+ But DCE's very name illustrates why it's a poor match for some
+ purposes -- DCE is intended for use in a large, multi-computer
+ distributed application.
+ In contrast, what's needed for desktop applications and
+ local OS communication is a very simple mechanism for
+ processes inside a single system to communicate.
+ DCE is a useful though complex
+ mechanism for complex needs, but that makes a poorer match
+ when you need a simple mechanism for simple needs.
+ </para>
+ </sect2>
+ <sect2 id="com">
+ <title>DCOM and COM</title>
+ <para>
+ <ulink url="http://www.microsoft.com/com/">COM</ulink>
+ is Microsoft's old approach to inter-application communication, and
+ DCOM is distributed COM.
+ But COM was not designed to be used on non-Windows systems.
+ The COM interface is notoriously hard to
+ use (e.g., its IDL, GUIDs and reference counting).
+ It is fragile as well; for example, the reference counting
+ makes it easy for minor problems in one application to cause
+ problems in other applications.
+ Security has been an issue as well.
+ COM+ partially addressed some of those issues, but added more
+ complexity.
+ DCOM uses DCE-like mechanisms, adding many complexities
+ that aren't needed for
+ simple desktop application and local machine communication.
+ In addition, Microsoft is deprecating this approach.
+ D-BUS tries to address the basic problem without this complexity.
+ </para>
+ </sect2>
+ <sect2 id="internet-communications-engine">
+ <title>ZeroC's Internet Communications Engine (Ice)</title>
+ <para>
+ The <ulink url="http://www.zeroc.com/ice.html">
+ Internet Communications Engine (Ice)</ulink>
+ is a powerful RPC mechanism.
+ But ICE does far, far more than is needed for D-BUS's applications,
+ adding unnecessary complexity for these purposes.
+ Ice
+ is available as GPL or as a proprietary (requiring royalty) license;
+ it's perceived that its licensing arrangement will reduce
+ the likelihood of widespread adoption by proprietary
+ software developers, which will inhibit adoption in general
+ as a general solution.
+ </para>
+ </sect2>
+ <sect2 id="inter-client-exchange">
+ <title>X Consortium's Inter-Client Exchange (ICE)</title>
+ <para>
+ <ulink url="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf">
+ Inter-Client Exchange (ICE)</ulink> is an X Consortium
+ mechanism for RPC (added in X11 R6.1).
+ However, this mechanism requires the use
+ of X, which does not work well for local systemwide messages --
+ especially since there may not even be a running X server.
+ Note that there are two RPC mechanisms with very similar names:
+ Inter-Client Exchange (ICE) and
+ with Internet Communications Engine (Ice).
+ </para>
+ </sect2>
+ <sect2 id="dcop">
+ <title>KDE's DCOP</title>
+ <para>
+ <ulink url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP</ulink>
+ is an RPC mechanism designed by KDE for its use,
+ after they determined that CORBA would not meet KDE's needs.
+ D-BUS was built based on experience from DCOP and is intentionally
+ designed to support an easy transition from DCOP to D-BUS.
+ In fact, it's fair to describe D-BUS as a
+ successor to DCOP designed to be independent of
+ X and the desktop environment.
+ </para>
+ <para>
+ However, there are some disadvantages to DCOP.
+ DCOP requires X's inter-client exchange (ICE), which means it
+ won't work well for systemwide messages (X may not even be running).
+ Also, DCOP doesn't have the security mechanisms that are needed
+ when trying to use it for systemwide messages.
+ Experience has identified some areas where DCOP is missing some
+ useful features; D-BUS is a little more elaborate and has added
+ those features that have been found to be important.
+ </para>
+ <para>
+ The common implementation DCOP depends on Qt;
+ this 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).
+ There are proof of concept implementations which don't depend on Qt,
+ but they are only proofs of concept.
+ GNOME application developers will not want to adopt a mechanism that
+ is dependent on Qt, and having a single IPC
+ mechanism for both GNOME and KDE applications will help improve
+ interoperation between those applications.
+ Qt dependence also imposes royalty payment requirements on
+ proprietary programs, even if they're not using Qt otherwise;
+ it's believed that this will impede acceptance of the IPC mechanism
+ beyond KDE.
+ </para>
+ <para>
+ D-BUS borrows many ideas from DCOP, but it's been reimplemented
+ to eliminate as many dependencies as practical.
+ The intended result is a "neutral" RPC mechanism that any
+ desktop environment can use without being at a disadvantage,
+ as well as being one that would be easy
+ for DCOP users to transition to.
+ At this time, KDE has not committed to using D-BUS, but there
+ have been discussions on the possibility of KDE bridging
+ D-BUS and DCOP, or even changing DCOP's implementation to use
+ D-BUS internally (so that GNOME and KDE would end up using
+ exactly the same bus).
+ </para>
+ </sect2>
+ <sect2 id="other-rpc">
+ <title>Other RPC Mechanisms</title>
+ <para>
+ There are many other RPC mechanisms; each have their issues.
+ Other mechanisms that have been looked at include
+ Sun ONC/RPC (which uses XDR) and MBUS (RFC 3259).
+ </para>
+ <para>
+ There are also some lower-level mechanisms for packing up data
+ that could be used to support RPC.
+ ISO's language ASN.1 (Abstract Syntax Notation) is excessively
+ complex for this purpose, and thus is rarely used for new
+ applications.
+ XDR (RFC 1832) requires all data
+ to be big-endian format; this format is
+ inconvenient and inefficient for many architectures, including
+ the extremely common x86s.
+ In contrast, D-BUS includes the endianness in the message,
+ so translations only occur when they're strictly necessary.
+ XDR doesn't include a UTF-8 type, which is helpful for ensuring
+ that strings with international characters are interpreted the
+ same way everywhere (and that UTF-8 errors can be detected
+ by the infrastructure).
+ Also, XDR by itself it doesn't include
+ type information in the message; such information
+ is very helpful for debugging and supports methods
+ with varying or optional parameters.
+ </para>
+ <para>
+ In general, D-BUS is designed to solve a specific problem
+ cleanly and easily, and thus it's expected to be very good
+ at this specific problem while other (typically more general)
+ solutions don't do as well at handling this specific case.
+ In contrast, there are many areas D-BUS isn't designed to address.
+ You certainly aren't required to use D-BUS, and for many
+ areas D-BUS may not be the right choice for you.
+ But hopefully you can see why D-BUS was created, and what it
+ is and is not good for.
+ </para>
+ </sect2>
+ </sect1>
</article>
+
More information about the dbus
mailing list