1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
|
<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.76.1"></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="#idp48080">
What is D-Bus?
</a></dt><dt>2. <a href="#idp51984">
Is D-Bus stable/finished?
</a></dt><dt>3. <a href="#idp55152">
How is the reference implementation licensed? Can I use it in
proprietary applications?
</a></dt><dt>4. <a href="#idp59104">
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="#idp4836432">
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="idp48080"></a><a name="idp48336"></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="idp51984"></a><a name="idp52240"></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="idp55152"></a><a name="idp55408"></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="idp59104"></a><a name="idp59360"></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="idp3746896"></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="idp3750112"></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="idp28640"></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="idp34160"></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="idp37280"></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="idp4762800"></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="idm35328"></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="idp4801888"></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="idp4806592"></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="idp4810864"></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="idp4814880"></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="idp4819504"></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="idp4826496"></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="idp4830432"></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="idp4836432"></a><a name="idp4836688"></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>
|
