1<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> 2 ����<code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code><br> 3 ��</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"> 4 What is D-Bus? 5 </a></dt><dt>2. <a href="#idp51984"> 6 Is D-Bus stable/finished? 7 </a></dt><dt>3. <a href="#idp55152"> 8 How is the reference implementation licensed? Can I use it in 9 proprietary applications? 10 </a></dt><dt>4. <a href="#idp59104"> 11 What is the difference between a bus name, and object path, 12 and an interface? 13 </a></dt><dt>5. <a href="#service"> 14 What is a "service"? 15 </a></dt><dt>6. <a href="#components"> 16 Is D-Bus a "component system"? 17 </a></dt><dt>7. <a href="#speed"> 18 How fast is the D-Bus reference implementation? 19 </a></dt><dt>8. <a href="#size"> 20 How large is the D-Bus reference implementation? 21 </a></dt><dt>9. <a href="#other-ipc"> 22 How does D-Bus differ from other interprocess communication 23 or networking protocols? 24 </a></dt><dt>10. <a href="#corba"> 25 How does D-Bus differ from CORBA? 26 </a></dt><dt>11. <a href="#xmlrpcsoap"> 27 How does D-Bus differ from XML-RPC and SOAP? 28 </a></dt><dt>12. <a href="#dce"> 29 How does D-Bus differ from DCE? 30 </a></dt><dt>13. <a href="#dcom"> 31 How does D-Bus differ from DCOM and COM? 32 </a></dt><dt>14. <a href="#internet-communications-engine"> 33 How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) 34 </a></dt><dt>15. <a href="#inter-client-exchange"> 35 How does D-Bus differ from Inter-Client Exchange (ICE)? 36 </a></dt><dt>16. <a href="#dcop"> 37 How does D-Bus differ from DCOP? 38 </a></dt><dt>17. <a href="#yet-more-ipc"> 39 How does D-Bus differ from [yet more IPC mechanisms]? 40 </a></dt><dt>18. <a href="#which-ipc"> 41 Which IPC mechanism should I use? 42 </a></dt><dt>19. <a href="#idp4836432"> 43 How can I submit a bug or patch? 44 </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> 45 What is D-Bus? 46 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 47 This is probably best answered by reading the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> or 48 the introduction to the <a class="ulink" href="dbus-specification.html" target="_top">specification</a>. In 49 short, it is a system consisting of 1) a wire protocol for exposing a 50 typical object-oriented language/framework to other applications; and 51 2) a bus daemon that allows applications to find and monitor one another. 52 Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level 53 structure (lifecycle tracking, service activation, security policy) provided by two bus daemons, 54 one systemwide and one per-user-session. 55 </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> 56 Is D-Bus stable/finished? 57 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 58 The low-level library "libdbus" and the protocol specification are considered 59 ABI stable. The <a class="ulink" href="README" target="_top">README</a> 60 file has a discussion of the API/ABI stability guarantees. 61 Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each 62 have their own release schedules and degree of maturity, not linked to 63 the low-level library and bus daemon release. Check the project page for 64 the binding you're considering to understand that project's policies. 65 </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> 66 How is the reference implementation licensed? Can I use it in 67 proprietary applications? 68 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 69 The short answer is yes, you can use it in proprietary applications. 70 You should read the <a class="ulink" href="COPYING" target="_top">COPYING</a> file, which 71 offers you the choice of two licenses. These are the GPL and the 72 AFL. The GPL requires that your application be licensed under the GPL 73 as well. The AFL is an "X-style" or "BSD-style" license compatible 74 with proprietary licensing, but it does have some requirements; in 75 particular it prohibits you from filing a lawsuit alleging that the 76 D-Bus software infringes your patents <span class="emphasis"><em>while you continue to 77 use D-Bus</em></span>. If you're going to sue, you have to stop using 78 the software. Read the licenses to determine their meaning, this FAQ 79 entry is not intended to change the meaning or terms of the licenses. 80 </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> 81 What is the difference between a bus name, and object path, 82 and an interface? 83 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 84 If you imagine a C++ program that implements a network service, then 85 the bus name is the hostname of the computer running this C++ program, 86 the object path is a C++ object instance pointer, and an interface is 87 a C++ class (a pure virtual or abstract class, to be exact). 88 </p><p> 89 In Java terms, the object path is an object reference, 90 and an interface is a Java interface. 91 </p><p> 92 People get confused because if they write an application 93 with a single object instance and a single interface, 94 then the bus name, object path, and interface look 95 redundant. For example, you might have a text editor 96 that uses the bus name <code class="literal">org.freedesktop.TextEditor</code>, 97 has a global singleton object called 98 <code class="literal">/org/freedesktop/TextEditor</code>, and 99 that singleton object could implement the interface 100 <code class="literal">org.freedesktop.TextEditor</code>. 101 </p><p> 102 However, a text editor application could as easily own multiple bus 103 names (for example, <code class="literal">org.kde.KWrite</code> in addition to 104 generic <code class="literal">TextEditor</code>), have multiple objects (maybe 105 <code class="literal">/org/kde/documents/4352</code> where the number changes 106 according to the document), and each object could implement multiple 107 interfaces, such as <code class="literal">org.freedesktop.DBus.Introspectable</code>, 108 <code class="literal">org.freedesktop.BasicTextField</code>, 109 <code class="literal">org.kde.RichTextDocument</code>. 110 </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> 111 What is a "service"? 112 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 113 A service is a program that can be launched by the bus daemon 114 to provide some functionality to other programs. Services 115 are normally launched according to the bus name they will 116 have. 117 </p><p> 118 People often misuse the word "service" for any 119 bus name, but this tends to be ambiguous and confusing so is discouraged. 120 In the D-Bus docs we try to use "service" only when talking about 121 programs the bus knows how to launch, i.e. a service always has a 122 .service file. 123 </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> 124 Is D-Bus a "component system"? 125 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 126 It helps to keep these concepts separate in your mind: 127 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> 128 Object/component system 129 </p></li><li class="listitem"><p> 130 GUI control/widget embedding interfaces 131 </p></li><li class="listitem"><p> 132 Interprocess communication system or wire protocol 133 </p></li></ol></div><p> 134 </p><p> 135 D-Bus is not a component system. "Component system" was originally 136 defined by COM, and was essentially a workaround for the limitations 137 of the C++ object system (adding introspection, runtime location of 138 objects, ABI guarantees, and so forth). With the C# language and CLR, 139 Microsoft added these features to the primary object system, leaving 140 COM obsolete. Similarly, Java has much less need for something like 141 COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer 142 some of the same features found in COM. 143 </p><p> 144 Component systems are not about GUI control embedding. Embedding 145 a spreadsheet in a word processor document is a matter of defining 146 some specific <span class="emphasis"><em>interfaces</em></span> that objects 147 can implement. These interfaces provide methods related to 148 GUI controls. So an object implementing those interfaces 149 can be embedded. 150 </p><p> 151 The word "component" just means "object with some fancy features" and 152 in modern languages all objects are effectively "components." 153 </p><p> 154 So components are fancy objects, and some objects are GUI controls. 155 </p><p> 156 A third, unrelated feature is interprocess communication or IPC. 157 D-Bus is an IPC system. Given an object (or "component" if you must), 158 you can expose the functionality of that object over an IPC system. 159 Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus. 160 You can use any of these IPC systems with any object/component system, 161 though some of them are "tuned" for specific object systems. 162 You can think of an IPC system primarily as a wire protocol. 163 </p><p> 164 If you combine an IPC system with a set of GUI control interfaces, 165 then you can have an out-of-process or dynamically-loaded GUI control. 166 </p><p> 167 Another related concept is the <em class="firstterm">plugin</em> or 168 <em class="firstterm">extension</em>. Generic plugin systems such as the 169 <a class="ulink" href="http://eclipse.org" target="_top">Eclipse</a> system are not so different 170 from component/object systems, though perhaps a "plugin" tends to be a 171 bundle of objects with a user-visible name and can be 172 downloaded/packaged as a unit. 173 </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> 174 How fast is the D-Bus reference implementation? 175 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 176 Of course it depends a bit on what you're doing. 177 <a class="ulink" href="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html" target="_top"> 178 This mail</a> contains some benchmarking. At the time of that 179 benchmark, D-Bus one-to-one communication was about 2.5x slower than 180 simply pushing the data raw over a socket. After the recent rewrite of 181 the marshaling code, D-Bus is slower than that because a lot of 182 optimization work was lost. But it can probably be sped up again. 183 </p><p> 184 D-Bus communication with the intermediate bus daemon should be 185 (and as last profiled, was) about twice as slow as one-to-one 186 mode, because a round trip involves four socket reads/writes rather 187 than two socket reads/writes. 188 </p><p> 189 The overhead comes from a couple of places; part of it is simply 190 "abstraction penalty" (there are layers of code to support 191 multiple main loops, multiple transport types, security, etc.). 192 Probably the largest part comes from data validation 193 (because the reference implementation does not trust incoming data). 194 It would be simple to add a "no validation" mode, but probably 195 not a good idea all things considered. 196 </p><p> 197 Raw bandwidth isn't the only concern; D-Bus is designed to 198 enable asynchronous communication and avoid round trips. 199 This is frequently a more important performance issue 200 than throughput. 201 </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> 202 How large is the D-Bus reference implementation? 203 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 204 A production build (with assertions, unit tests, and verbose logging 205 disabled) is on the order of a 150K shared library. 206 </p><p> 207 A much, much smaller implementation would be possible by omitting out 208 of memory handling, hardcoding a main loop (or always using blocking 209 I/O), skipping validation, and otherwise simplifying things. 210 </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> 211 How does D-Bus differ from other interprocess communication 212 or networking protocols? 213 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 214 Keep in mind, it is not only an IPC system; it also includes 215 lifecycle tracking, service activation, security policy, and other 216 higher-level structure and assumptions. 217 </p><p> 218 The best place to start is to read the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a>, so 219 you have a concrete idea what D-Bus actually is. If you 220 understand other protocols on a wire format level, you 221 may also want to read the D-Bus <a class="ulink" href="dbus-specification.html" target="_top">specification</a> to see what 222 D-Bus looks like on a low level. 223 </p><p> 224 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 225 for some specific use cases. Thus, it probably isn't tuned 226 for what you want to do, unless you are doing the things 227 D-Bus was designed for. Don't make the mistake of thinking 228 that any system involving "IPC" is the same thing. 229 </p><p> 230 The D-Bus authors would not recommend using D-Bus 231 for applications where it doesn't make sense. 232 The following questions compare D-Bus to some other 233 protocols primarily to help you understand D-Bus 234 and decide whether it's appropriate; D-Bus is neither intended 235 nor claimed to be the right choice for every application. 236 </p><p> 237 It should be possible to bridge D-Bus to other IPC systems, 238 just as D-Bus can be bridged to object systems. 239 </p><p> 240 Note: the D-Bus mailing list subscribers are <span class="emphasis"><em>very much not 241 interested</em></span> in debating which IPC system is the One True 242 System. So if you want to discuss that, please use another forum. 243 </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> 244 How does D-Bus differ from CORBA? 245 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 246 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 247 </p><p> 248 <a class="ulink" href="http://www.omg.org" target="_top">CORBA</a> is designed to support 249 object-oriented IPC between objects, automatically marshalling 250 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 251 produces various standards and supporting documents for CORBA and has 252 the backing of many large organizations. There are many CORBA ORBs 253 available, both proprietary ORBs and free / open source software ORBs 254 (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 255 organizations continue to use CORBA ORBs for various kinds of IPC. 256 </p><p> 257 Both GNOME and KDE have used CORBA and then moved away from it. KDE 258 had more success with a system called DCOP, and GNOME layered a system 259 called Bonobo on top of CORBA. Without custom extensions, CORBA does 260 not support many of the things one wants to do in a desktop 261 environment with the GNOME/KDE architecture. 262 </p><p> 263 CORBA on the other hand has a number of features of interest for 264 enterprise and web application development, though XML systems such as 265 SOAP are the latest fad. 266 </p><p> 267 Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems 268 work in terms of objects and methods, and have concepts such as 269 "oneway" calls. Only D-Bus has direct support for "signals" as in 270 GLib/Qt (or Java listeners, or C# delegates). 271 </p><p> 272 D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, 273 because CORBA is more generic and D-Bus has two specific use-cases in mind. 274 This makes D-Bus a bit simpler. 275 </p><p> 276 However, unlike CORBA D-Bus does <span class="emphasis"><em>not</em></span> specify the 277 API for the language bindings. Instead, "native" bindings adapted 278 specifically to the conventions of a framework such as QObject, 279 GObject, C#, Java, Python, etc. are encouraged. The libdbus reference 280 implementation is designed to be a backend for bindings of this 281 nature, rather than to be used directly. The rationale is that an IPC 282 system API should not "leak" all over a program; it should come into 283 play only just before data goes over the wire. As an aside, OMG is 284 apparently working on a simpler C++ binding for CORBA. 285 </p><p> 286 Many CORBA implementations such as ORBit are faster than the libdbus 287 reference implementation. One reason is that D-Bus considers data 288 from the other end of the connection to be untrusted and extensively 289 validates it. But generally speaking other priorities were placed 290 ahead of raw speed in the libdbus implementation. A fast D-Bus 291 implementation along the lines of ORBit should be possible, of course. 292 </p><p> 293 On a more trivial note, D-Bus involves substantially fewer acronyms 294 than CORBA. 295 </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> 296 How does D-Bus differ from XML-RPC and SOAP? 297 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 298 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 299 </p><p> 300 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 301 into an XML-based format, then sent over the wire (typically using the 302 HTTP protocol), where they are processed and returned. XML-RPC is the 303 simple protocol (its spec is only a page or two), and SOAP is the 304 full-featured protocol. 305 </p><p> 306 XML-RPC and SOAP impose XML parsing overhead that is normally 307 irrelevant in the context of the Internet, but significant for 308 constant fine-grained IPC among applications in a desktop session. 309 </p><p> 310 D-Bus offers persistent connections and with the bus daemon 311 supports lifecycle tracking of other applications connected 312 to the bus. With XML-RPC and SOAP, typically each method call 313 exists in isolation and has its own HTTP connection. 314 </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> 315 How does D-Bus differ from DCE? 316 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 317 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 318 </p><p> 319 <a class="ulink" href="http://www.opengroup.org/dce/" target="_top">Distributed Computing 320 Environment (DCE)</a> is an industry-standard vendor-neutral 321 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 322 has released an implementation as open source software</a>. DCE 323 is quite capable, and includes a vast amount of functionality such as 324 a distributed time service. As the name implies, DCE is intended for 325 use in a large, multi-computer distributed application. D-Bus would 326 not be well-suited for this. 327 </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> 328 How does D-Bus differ from DCOM and COM? 329 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 330 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 331 </p><p> 332 Comparing D-Bus to COM is apples and oranges; 333 see <a class="xref" href="#components" title="6.">Q:�6</a>. 334 </p><p> 335 DCOM (distributed COM) is a Windows IPC system designed for use with 336 the COM object system. It's similar in some ways to DCE and CORBA. 337 </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> 338 How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) 339 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 340 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 341 </p><p> 342 The <a class="ulink" href="http://www.zeroc.com/ice.html" target="_top"> Internet 343 Communications Engine (Ice)</a> is a powerful IPC mechanism more 344 on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license" 345 business around it; i.e. you can use it under the GPL, or pay for a 346 proprietary license. 347 </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> 348 How does D-Bus differ from Inter-Client Exchange (ICE)? 349 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 350 <a class="ulink" href="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf" target="_top">ICE</a> 351 was developed for the X Session Management protocol (XSMP), as part of 352 the X Window System (X11R6.1). The idea was to allow desktop sessions 353 to contain nongraphical clients in addition to X clients. 354 </p><p> 355 ICE is a binary protocol designed for desktop use, and KDE's DCOP 356 builds on ICE. ICE is substantially simpler than D-Bus (in contrast 357 to most of the other IPC systems mentioned here, which are more 358 complex). ICE doesn't really define a mapping to objects and methods 359 (DCOP adds that layer). The reference implementation of ICE (libICE) 360 is often considered to be horrible (and horribly insecure). 361 </p><p> 362 DCOP and XSMP are the only two widely-used applications of ICE, 363 and both could in principle be replaced by D-Bus. (Though whether 364 GNOME and KDE will bother is an open question.) 365 </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> 366 How does D-Bus differ from DCOP? 367 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 368 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 369 </p><p> 370 D-Bus is intentionally pretty similar to <a class="ulink" href="http://developer.kde.org/documentation/library/kdeqt/dcop.html" target="_top">DCOP</a>, 371 and can be thought of as a "DCOP the next generation" suitable for 372 sharing between the various open source desktop projects. 373 </p><p> 374 D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus 375 should not be more complex for programmers. The additional complexity 376 of D-Bus arises from its separation of object references vs. bus names 377 vs. interfaces as distinct concepts, and its support for one-to-one 378 connections in addition to connections over the bus. The libdbus 379 reference implementation has a lot of API to support multiple bindings 380 and main loops, and performs data validation and out-of-memory handling 381 in order to support secure applications such as the systemwide bus. 382 </p><p> 383 D-Bus is probably somewhat slower than DCOP due to data validation 384 and more "layers" in the reference implementation. A comparison 385 hasn't been posted to the list though. 386 </p><p> 387 At this time, KDE has not committed to using D-Bus, but there have 388 been discussions of KDE bridging D-Bus and DCOP, or even changing 389 DCOP's implementation to use D-Bus internally (so that GNOME and KDE 390 would end up using exactly the same bus). See the KDE mailing list 391 archives for some of these discussions. 392 </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> 393 How does D-Bus differ from [yet more IPC mechanisms]? 394 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 395 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 396 </p><p> 397 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, 398 SIP, are some we can think of quickly. 399 </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> 400 Which IPC mechanism should I use? 401 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 402 Start by reading <a class="xref" href="#other-ipc" title="9.">Q:�9</a>. 403 </p><p> 404 If you're writing an Internet or Intranet application, XML-RPC or SOAP 405 work for many people. These are standard, available for most 406 languages, simple to debug and easy to use. 407 </p><p> 408 If you're writing a desktop application for UNIX, 409 then D-Bus is of course our recommendation for 410 talking to other parts of the desktop session. 411 </p><p> 412 D-Bus is also designed for communications between system daemons and 413 communications between the desktop and system daemons. 414 </p><p> 415 If you're doing something complicated such as clustering, 416 distributed swarms, peer-to-peer, or whatever then 417 the authors of this FAQ don't have expertise in these 418 areas and you should ask someone else or try a search engine. 419 D-Bus is most likely a poor choice but could be appropriate 420 for some things. 421 </p><p> 422 Note: the D-Bus mailing list is probably not the place to 423 discuss which system is appropriate for your application, 424 though you are welcome to ask specific questions about 425 D-Bus <span class="emphasis"><em>after reading this FAQ, the tutorial, and 426 searching the list archives</em></span>. The best way 427 to search the list archives is probably to use 428 an Internet engine such as Google. On Google, 429 include "site:freedesktop.org" in your search. 430 </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> 431 How can I submit a bug or patch? 432 </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> 433 The D-Bus <a class="ulink" href="http://dbus.freedesktop.org" target="_top">web site</a> 434 has a link to the bug tracker, which is the best place to store 435 patches. You can also post them to the list, especially if you want 436 to discuss the patch or get feedback. 437 </p></td></tr></tbody></table></div></div></body></html> 438