<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus FAQ</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus FAQ"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus FAQ</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> | |
<code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code><br> | |
</p></div></div></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="othername">A</span> <span class="surname">Wheeler</span></h3></div></div></div><div><p class="releaseinfo">Version 0.3</p></div></div><hr></div><div class="qandaset" title="Frequently Asked Questions"><a name="faq"></a><dl><dt>1. <a href="#idp24880640"> | |
What is D-Bus? | |
</a></dt><dt>2. <a href="#idp28175104"> | |
Is D-Bus stable/finished? | |
</a></dt><dt>3. <a href="#idp28178272"> | |
How is the reference implementation licensed? Can I use it in | |
proprietary applications? | |
</a></dt><dt>4. <a href="#idp24480960"> | |
What is the difference between a bus name, and object path, | |
and an interface? | |
</a></dt><dt>5. <a href="#service"> | |
What is a "service"? | |
</a></dt><dt>6. <a href="#components"> | |
Is D-Bus a "component system"? | |
</a></dt><dt>7. <a href="#speed"> | |
How fast is the D-Bus reference implementation? | |
</a></dt><dt>8. <a href="#size"> | |
How large is the D-Bus reference implementation? | |
</a></dt><dt>9. <a href="#other-ipc"> | |
How does D-Bus differ from other interprocess communication | |
or networking protocols? | |
</a></dt><dt>10. <a href="#corba"> | |
How does D-Bus differ from CORBA? | |
</a></dt><dt>11. <a href="#xmlrpcsoap"> | |
How does D-Bus differ from XML-RPC and SOAP? | |
</a></dt><dt>12. <a href="#dce"> | |
How does D-Bus differ from DCE? | |
</a></dt><dt>13. <a href="#dcom"> | |
How does D-Bus differ from DCOM and COM? | |
</a></dt><dt>14. <a href="#internet-communications-engine"> | |
How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) | |
</a></dt><dt>15. <a href="#inter-client-exchange"> | |
How does D-Bus differ from Inter-Client Exchange (ICE)? | |
</a></dt><dt>16. <a href="#dcop"> | |
How does D-Bus differ from DCOP? | |
</a></dt><dt>17. <a href="#yet-more-ipc"> | |
How does D-Bus differ from [yet more IPC mechanisms]? | |
</a></dt><dt>18. <a href="#which-ipc"> | |
Which IPC mechanism should I use? | |
</a></dt><dt>19. <a href="#idp29282704"> | |
How can I submit a bug or patch? | |
</a></dt></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%"><col><tbody><tr class="question" title="1."><td align="left" valign="top"><a name="idp24880640"></a><a name="idp24880896"></a><p><b>1.</b></p></td><td align="left" valign="top"><p> | |
What is D-Bus? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
This is probably best answered by reading the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> or | |
the introduction to the <a class="ulink" href="dbus-specification.html" target="_top">specification</a>. In | |
short, it is a system consisting of 1) a wire protocol for exposing a | |
typical object-oriented language/framework to other applications; and | |
2) a bus daemon that allows applications to find and monitor one another. | |
Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level | |
structure (lifecycle tracking, service activation, security policy) provided by two bus daemons, | |
one systemwide and one per-user-session. | |
</p></td></tr><tr class="question" title="2."><td align="left" valign="top"><a name="idp28175104"></a><a name="idp28175360"></a><p><b>2.</b></p></td><td align="left" valign="top"><p> | |
Is D-Bus stable/finished? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
The low-level library "libdbus" and the protocol specification are considered | |
ABI stable. The <a class="ulink" href="README" target="_top">README</a> | |
file has a discussion of the API/ABI stability guarantees. | |
Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each | |
have their own release schedules and degree of maturity, not linked to | |
the low-level library and bus daemon release. Check the project page for | |
the binding you're considering to understand that project's policies. | |
</p></td></tr><tr class="question" title="3."><td align="left" valign="top"><a name="idp28178272"></a><a name="idp28178528"></a><p><b>3.</b></p></td><td align="left" valign="top"><p> | |
How is the reference implementation licensed? Can I use it in | |
proprietary applications? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
The short answer is yes, you can use it in proprietary applications. | |
You should read the <a class="ulink" href="COPYING" target="_top">COPYING</a> file, which | |
offers you the choice of two licenses. These are the GPL and the | |
AFL. The GPL requires that your application be licensed under the GPL | |
as well. The AFL is an "X-style" or "BSD-style" license compatible | |
with proprietary licensing, but it does have some requirements; in | |
particular it prohibits you from filing a lawsuit alleging that the | |
D-Bus software infringes your patents <span class="emphasis"><em>while you continue to | |
use D-Bus</em></span>. If you're going to sue, you have to stop using | |
the software. Read the licenses to determine their meaning, this FAQ | |
entry is not intended to change the meaning or terms of the licenses. | |
</p></td></tr><tr class="question" title="4."><td align="left" valign="top"><a name="idp24480960"></a><a name="idp24481216"></a><p><b>4.</b></p></td><td align="left" valign="top"><p> | |
What is the difference between a bus name, and object path, | |
and an interface? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
If you imagine a C++ program that implements a network service, then | |
the bus name is the hostname of the computer running this C++ program, | |
the object path is a C++ object instance pointer, and an interface is | |
a C++ class (a pure virtual or abstract class, to be exact). | |
</p><p> | |
In Java terms, the object path is an object reference, | |
and an interface is a Java interface. | |
</p><p> | |
People get confused because if they write an application | |
with a single object instance and a single interface, | |
then the bus name, object path, and interface look | |
redundant. For example, you might have a text editor | |
that uses the bus name <code class="literal">org.freedesktop.TextEditor</code>, | |
has a global singleton object called | |
<code class="literal">/org/freedesktop/TextEditor</code>, and | |
that singleton object could implement the interface | |
<code class="literal">org.freedesktop.TextEditor</code>. | |
</p><p> | |
However, a text editor application could as easily own multiple bus | |
names (for example, <code class="literal">org.kde.KWrite</code> in addition to | |
generic <code class="literal">TextEditor</code>), have multiple objects (maybe | |
<code class="literal">/org/kde/documents/4352</code> where the number changes | |
according to the document), and each object could implement multiple | |
interfaces, such as <code class="literal">org.freedesktop.DBus.Introspectable</code>, | |
<code class="literal">org.freedesktop.BasicTextField</code>, | |
<code class="literal">org.kde.RichTextDocument</code>. | |
</p></td></tr><tr class="question" title="5."><td align="left" valign="top"><a name="service"></a><a name="idp24498144"></a><p><b>5.</b></p></td><td align="left" valign="top"><p> | |
What is a "service"? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
A service is a program that can be launched by the bus daemon | |
to provide some functionality to other programs. Services | |
are normally launched according to the bus name they will | |
have. | |
</p><p> | |
People often misuse the word "service" for any | |
bus name, but this tends to be ambiguous and confusing so is discouraged. | |
In the D-Bus docs we try to use "service" only when talking about | |
programs the bus knows how to launch, i.e. a service always has a | |
.service file. | |
</p></td></tr><tr class="question" title="6."><td align="left" valign="top"><a name="components"></a><a name="idp24501360"></a><p><b>6.</b></p></td><td align="left" valign="top"><p> | |
Is D-Bus a "component system"? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
It helps to keep these concepts separate in your mind: | |
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> | |
Object/component system | |
</p></li><li class="listitem"><p> | |
GUI control/widget embedding interfaces | |
</p></li><li class="listitem"><p> | |
Interprocess communication system or wire protocol | |
</p></li></ol></div><p> | |
</p><p> | |
D-Bus is not a component system. "Component system" was originally | |
defined by COM, and was essentially a workaround for the limitations | |
of the C++ object system (adding introspection, runtime location of | |
objects, ABI guarantees, and so forth). With the C# language and CLR, | |
Microsoft added these features to the primary object system, leaving | |
COM obsolete. Similarly, Java has much less need for something like | |
COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer | |
some of the same features found in COM. | |
</p><p> | |
Component systems are not about GUI control embedding. Embedding | |
a spreadsheet in a word processor document is a matter of defining | |
some specific <span class="emphasis"><em>interfaces</em></span> that objects | |
can implement. These interfaces provide methods related to | |
GUI controls. So an object implementing those interfaces | |
can be embedded. | |
</p><p> | |
The word "component" just means "object with some fancy features" and | |
in modern languages all objects are effectively "components." | |
</p><p> | |
So components are fancy objects, and some objects are GUI controls. | |
</p><p> | |
A third, unrelated feature is interprocess communication or IPC. | |
D-Bus is an IPC system. Given an object (or "component" if you must), | |
you can expose the functionality of that object over an IPC system. | |
Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus. | |
You can use any of these IPC systems with any object/component system, | |
though some of them are "tuned" for specific object systems. | |
You can think of an IPC system primarily as a wire protocol. | |
</p><p> | |
If you combine an IPC system with a set of GUI control interfaces, | |
then you can have an out-of-process or dynamically-loaded GUI control. | |
</p><p> | |
Another related concept is the <em class="firstterm">plugin</em> or | |
<em class="firstterm">extension</em>. Generic plugin systems such as the | |
<a class="ulink" href="http://eclipse.org" target="_top">Eclipse</a> system are not so different | |
from component/object systems, though perhaps a "plugin" tends to be a | |
bundle of objects with a user-visible name and can be | |
downloaded/packaged as a unit. | |
</p></td></tr><tr class="question" title="7."><td align="left" valign="top"><a name="speed"></a><a name="idp24513904"></a><p><b>7.</b></p></td><td align="left" valign="top"><p> | |
How fast is the D-Bus reference implementation? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Of course it depends a bit on what you're doing. | |
<a class="ulink" href="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html" target="_top"> | |
This mail</a> contains some benchmarking. At the time of that | |
benchmark, D-Bus one-to-one communication was about 2.5x slower than | |
simply pushing the data raw over a socket. After the recent rewrite of | |
the marshaling code, D-Bus is slower than that because a lot of | |
optimization work was lost. But it can probably be sped up again. | |
</p><p> | |
D-Bus communication with the intermediate bus daemon should be | |
(and as last profiled, was) about twice as slow as one-to-one | |
mode, because a round trip involves four socket reads/writes rather | |
than two socket reads/writes. | |
</p><p> | |
The overhead comes from a couple of places; part of it is simply | |
"abstraction penalty" (there are layers of code to support | |
multiple main loops, multiple transport types, security, etc.). | |
Probably the largest part comes from data validation | |
(because the reference implementation does not trust incoming data). | |
It would be simple to add a "no validation" mode, but probably | |
not a good idea all things considered. | |
</p><p> | |
Raw bandwidth isn't the only concern; D-Bus is designed to | |
enable asynchronous communication and avoid round trips. | |
This is frequently a more important performance issue | |
than throughput. | |
</p></td></tr><tr class="question" title="8."><td align="left" valign="top"><a name="size"></a><a name="idp29197488"></a><p><b>8.</b></p></td><td align="left" valign="top"><p> | |
How large is the D-Bus reference implementation? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
A production build (with assertions, unit tests, and verbose logging | |
disabled) is on the order of a 150K shared library. | |
</p><p> | |
A much, much smaller implementation would be possible by omitting out | |
of memory handling, hardcoding a main loop (or always using blocking | |
I/O), skipping validation, and otherwise simplifying things. | |
</p></td></tr><tr class="question" title="9."><td align="left" valign="top"><a name="other-ipc"></a><a name="idp29200448"></a><p><b>9.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from other interprocess communication | |
or networking protocols? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Keep in mind, it is not only an IPC system; it also includes | |
lifecycle tracking, service activation, security policy, and other | |
higher-level structure and assumptions. | |
</p><p> | |
The best place to start is to read the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a>, so | |
you have a concrete idea what D-Bus actually is. If you | |
understand other protocols on a wire format level, you | |
may also want to read the D-Bus <a class="ulink" href="dbus-specification.html" target="_top">specification</a> to see what | |
D-Bus looks like on a low level. | |
</p><p> | |
As the <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> and <a class="ulink" href="dbus-specification.html" target="_top">specification</a> both explain, D-Bus is tuned | |
for some specific use cases. Thus, it probably isn't tuned | |
for what you want to do, unless you are doing the things | |
D-Bus was designed for. Don't make the mistake of thinking | |
that any system involving "IPC" is the same thing. | |
</p><p> | |
The D-Bus authors would not recommend using D-Bus | |
for applications where it doesn't make sense. | |
The following questions compare D-Bus to some other | |
protocols primarily to help you understand D-Bus | |
and decide whether it's appropriate; D-Bus is neither intended | |
nor claimed to be the right choice for every application. | |
</p><p> | |
It should be possible to bridge D-Bus to other IPC systems, | |
just as D-Bus can be bridged to object systems. | |
</p><p> | |
Note: the D-Bus mailing list subscribers are <span class="emphasis"><em>very much not | |
interested</em></span> in debating which IPC system is the One True | |
System. So if you want to discuss that, please use another forum. | |
</p></td></tr><tr class="question" title="10."><td align="left" valign="top"><a name="corba"></a><a name="idp29208976"></a><p><b>10.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from CORBA? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
<a class="ulink" href="http://www.omg.org" target="_top">CORBA</a> is designed to support | |
object-oriented IPC between objects, automatically marshalling | |
parameters as necessary. CORBA is strongly supported by the <a class="ulink" href="http://www.omg.org" target="_top">Open Management Group (OMG)</a>, 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 <a class="ulink" href="http://orbit-resource.sourceforge.net/" target="_top">ORBit</a>, <a class="ulink" href="http://www.mico.org/" target="_top">MICO</a>, and <a class="ulink" href="http://www.theaceorb.com/" target="_top">The ACE Orb (TAO)</a>). Many | |
organizations continue to use CORBA ORBs for various kinds of IPC. | |
</p><p> | |
Both GNOME and KDE have used CORBA and then moved away from it. KDE | |
had more success with a system called DCOP, and GNOME layered a system | |
called Bonobo on top of CORBA. Without custom extensions, CORBA does | |
not support many of the things one wants to do in a desktop | |
environment with the GNOME/KDE architecture. | |
</p><p> | |
CORBA on the other hand has a number of features of interest for | |
enterprise and web application development, though XML systems such as | |
SOAP are the latest fad. | |
</p><p> | |
Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems | |
work in terms of objects and methods, and have concepts such as | |
"oneway" calls. Only D-Bus has direct support for "signals" as in | |
GLib/Qt (or Java listeners, or C# delegates). | |
</p><p> | |
D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, | |
because CORBA is more generic and D-Bus has two specific use-cases in mind. | |
This makes D-Bus a bit simpler. | |
</p><p> | |
However, unlike CORBA D-Bus does <span class="emphasis"><em>not</em></span> specify the | |
API for the language bindings. Instead, "native" bindings adapted | |
specifically to the conventions of a framework such as QObject, | |
GObject, C#, Java, Python, etc. are encouraged. The libdbus reference | |
implementation is designed to be a backend for bindings of this | |
nature, rather than to be used directly. The rationale is that an IPC | |
system API should not "leak" all over a program; it should come into | |
play only just before data goes over the wire. As an aside, OMG is | |
apparently working on a simpler C++ binding for CORBA. | |
</p><p> | |
Many CORBA implementations such as ORBit are faster than the libdbus | |
reference implementation. One reason is that D-Bus considers data | |
from the other end of the connection to be untrusted and extensively | |
validates it. But generally speaking other priorities were placed | |
ahead of raw speed in the libdbus implementation. A fast D-Bus | |
implementation along the lines of ORBit should be possible, of course. | |
</p><p> | |
On a more trivial note, D-Bus involves substantially fewer acronyms | |
than CORBA. | |
</p></td></tr><tr class="question" title="11."><td align="left" valign="top"><a name="xmlrpcsoap"></a><a name="idp24449648"></a><p><b>11.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from XML-RPC and SOAP? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
In <a class="ulink" href="http://www.w3.org/TR/SOAP/" target="_top">SOAP</a> and <a class="ulink" href="http://www.xmlrpc.com" target="_top">XML-RPC</a>, 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. XML-RPC is the | |
simple protocol (its spec is only a page or two), and SOAP is the | |
full-featured protocol. | |
</p><p> | |
XML-RPC and SOAP impose XML parsing overhead that is normally | |
irrelevant in the context of the Internet, but significant for | |
constant fine-grained IPC among applications in a desktop session. | |
</p><p> | |
D-Bus offers persistent connections and with the bus daemon | |
supports lifecycle tracking of other applications connected | |
to the bus. With XML-RPC and SOAP, typically each method call | |
exists in isolation and has its own HTTP connection. | |
</p></td></tr><tr class="question" title="12."><td align="left" valign="top"><a name="dce"></a><a name="idp29248064"></a><p><b>12.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from DCE? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
<a class="ulink" href="http://www.opengroup.org/dce/" target="_top">Distributed Computing | |
Environment (DCE)</a> is an industry-standard vendor-neutral | |
standard that includes an IPC mechanism. <a class="ulink" href="http://www.opengroup.org/comm/press/05-01-12.htm" target="_top">The Open Group | |
has released an implementation as open source software</a>. DCE | |
is quite capable, and includes a vast amount of functionality such as | |
a distributed time service. As the name implies, DCE is intended for | |
use in a large, multi-computer distributed application. D-Bus would | |
not be well-suited for this. | |
</p></td></tr><tr class="question" title="13."><td align="left" valign="top"><a name="dcom"></a><a name="idp29252864"></a><p><b>13.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from DCOM and COM? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
Comparing D-Bus to COM is apples and oranges; | |
see <a class="xref" href="#components" title="6.">Q: 6</a>. | |
</p><p> | |
DCOM (distributed COM) is a Windows IPC system designed for use with | |
the COM object system. It's similar in some ways to DCE and CORBA. | |
</p></td></tr><tr class="question" title="14."><td align="left" valign="top"><a name="internet-communications-engine"></a><a name="idp29257136"></a><p><b>14.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
The <a class="ulink" href="http://www.zeroc.com/ice.html" target="_top"> Internet | |
Communications Engine (Ice)</a> is a powerful IPC mechanism more | |
on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license" | |
business around it; i.e. you can use it under the GPL, or pay for a | |
proprietary license. | |
</p></td></tr><tr class="question" title="15."><td align="left" valign="top"><a name="inter-client-exchange"></a><a name="idp29261152"></a><p><b>15.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from Inter-Client Exchange (ICE)? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
<a class="ulink" href="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf" target="_top">ICE</a> | |
was developed for the X Session Management protocol (XSMP), as part of | |
the X Window System (X11R6.1). The idea was to allow desktop sessions | |
to contain nongraphical clients in addition to X clients. | |
</p><p> | |
ICE is a binary protocol designed for desktop use, and KDE's DCOP | |
builds on ICE. ICE is substantially simpler than D-Bus (in contrast | |
to most of the other IPC systems mentioned here, which are more | |
complex). ICE doesn't really define a mapping to objects and methods | |
(DCOP adds that layer). The reference implementation of ICE (libICE) | |
is often considered to be horrible (and horribly insecure). | |
</p><p> | |
DCOP and XSMP are the only two widely-used applications of ICE, | |
and both could in principle be replaced by D-Bus. (Though whether | |
GNOME and KDE will bother is an open question.) | |
</p></td></tr><tr class="question" title="16."><td align="left" valign="top"><a name="dcop"></a><a name="idp29265776"></a><p><b>16.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from DCOP? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
D-Bus is intentionally pretty similar to <a class="ulink" href="http://developer.kde.org/documentation/library/kdeqt/dcop.html" target="_top">DCOP</a>, | |
and can be thought of as a "DCOP the next generation" suitable for | |
sharing between the various open source desktop projects. | |
</p><p> | |
D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus | |
should not be more complex for programmers. The additional complexity | |
of D-Bus arises from its separation of object references vs. bus names | |
vs. interfaces as distinct concepts, and its support for one-to-one | |
connections in addition to connections over the bus. The libdbus | |
reference implementation has a lot of API to support multiple bindings | |
and main loops, and performs data validation and out-of-memory handling | |
in order to support secure applications such as the systemwide bus. | |
</p><p> | |
D-Bus is probably somewhat slower than DCOP due to data validation | |
and more "layers" in the reference implementation. A comparison | |
hasn't been posted to the list though. | |
</p><p> | |
At this time, KDE has not committed to using D-Bus, but there have | |
been discussions 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). See the KDE mailing list | |
archives for some of these discussions. | |
</p></td></tr><tr class="question" title="17."><td align="left" valign="top"><a name="yet-more-ipc"></a><a name="idp29272768"></a><p><b>17.</b></p></td><td align="left" valign="top"><p> | |
How does D-Bus differ from [yet more IPC mechanisms]? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
There are countless uses of network sockets in the world. <a class="ulink" href="http://www.mbus.org/" target="_top">MBUS</a>, Sun ONC/RPC, Jabber/XMPP, | |
SIP, are some we can think of quickly. | |
</p></td></tr><tr class="question" title="18."><td align="left" valign="top"><a name="which-ipc"></a><a name="idp29276704"></a><p><b>18.</b></p></td><td align="left" valign="top"><p> | |
Which IPC mechanism should I use? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. | |
</p><p> | |
If you're writing an Internet or Intranet application, XML-RPC or SOAP | |
work for many people. These are standard, available for most | |
languages, simple to debug and easy to use. | |
</p><p> | |
If you're writing a desktop application for UNIX, | |
then D-Bus is of course our recommendation for | |
talking to other parts of the desktop session. | |
</p><p> | |
D-Bus is also designed for communications between system daemons and | |
communications between the desktop and system daemons. | |
</p><p> | |
If you're doing something complicated such as clustering, | |
distributed swarms, peer-to-peer, or whatever then | |
the authors of this FAQ don't have expertise in these | |
areas and you should ask someone else or try a search engine. | |
D-Bus is most likely a poor choice but could be appropriate | |
for some things. | |
</p><p> | |
Note: the D-Bus mailing list is probably not the place to | |
discuss which system is appropriate for your application, | |
though you are welcome to ask specific questions about | |
D-Bus <span class="emphasis"><em>after reading this FAQ, the tutorial, and | |
searching the list archives</em></span>. The best way | |
to search the list archives is probably to use | |
an Internet engine such as Google. On Google, | |
include "site:freedesktop.org" in your search. | |
</p></td></tr><tr class="question" title="19."><td align="left" valign="top"><a name="idp29282704"></a><a name="idp29282960"></a><p><b>19.</b></p></td><td align="left" valign="top"><p> | |
How can I submit a bug or patch? | |
</p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> | |
The D-Bus <a class="ulink" href="http://dbus.freedesktop.org" target="_top">web site</a> | |
has a link to the bug tracker, which is the best place to store | |
patches. You can also post them to the list, especially if you want | |
to discuss the patch or get feedback. | |
</p></td></tr></tbody></table></div></div></body></html> |