1 <?xml version="1.0" standalone="no"?> 2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" 4 [ 5 ]> 6 7 <article id="index"> 8 <articleinfo> 9 <title>D-Bus FAQ</title> 10 <releaseinfo>Version 0.3</releaseinfo> 11 <date>17 November 2006</date> 12 <authorgroup> 13 <author> 14 <firstname>Havoc</firstname> 15 <surname>Pennington</surname> 16 <affiliation> 17 <orgname>Red Hat, Inc.</orgname> 18 <address> 19 <email>hp (a] pobox.com</email> 20 </address> 21 </affiliation> 22 </author> 23 <author> 24 <firstname>David</firstname> 25 <othername role="mi">A</othername> 26 <surname>Wheeler</surname> 27 </author> 28 </authorgroup> 29 </articleinfo> 30 31 <qandaset id="faq"> 32 33 <qandaentry> 34 <question> 35 <para> 36 What is D-Bus? 37 </para> 38 </question> 39 <answer> 40 <para> 41 This is probably best answered by reading the D-Bus <ulink url="dbus-tutorial.html">tutorial</ulink> or 42 the introduction to the <ulink url="dbus-specification.html">specification</ulink>. In 43 short, it is a system consisting of 1) a wire protocol for exposing a 44 typical object-oriented language/framework to other applications; and 45 2) a bus daemon that allows applications to find and monitor one another. 46 Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level 47 structure (lifecycle tracking, service activation, security policy) provided by two bus daemons, 48 one systemwide and one per-user-session. 49 </para> 50 </answer> 51 </qandaentry> 52 53 <qandaentry> 54 <question> 55 <para> 56 Is D-Bus stable/finished? 57 </para> 58 </question> 59 <answer> 60 <para> 61 The low-level library "libdbus" and the protocol specification are considered 62 ABI stable. The <ulink url="README">README</ulink> 63 file has a discussion of the API/ABI stability guarantees. 64 Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each 65 have their own release schedules and degree of maturity, not linked to 66 the low-level library and bus daemon release. Check the project page for 67 the binding you're considering to understand that project's policies. 68 </para> 69 </answer> 70 </qandaentry> 71 72 <qandaentry> 73 <question> 74 <para> 75 How is the reference implementation licensed? Can I use it in 76 proprietary applications? 77 </para> 78 </question> 79 <answer> 80 <para> 81 The short answer is yes, you can use it in proprietary applications. 82 You should read the <ulink url="COPYING">COPYING</ulink> file, which 83 offers you the choice of two licenses. These are the GPL and the 84 AFL. The GPL requires that your application be licensed under the GPL 85 as well. The AFL is an "X-style" or "BSD-style" license compatible 86 with proprietary licensing, but it does have some requirements; in 87 particular it prohibits you from filing a lawsuit alleging that the 88 D-Bus software infringes your patents <emphasis>while you continue to 89 use D-Bus</emphasis>. If you're going to sue, you have to stop using 90 the software. Read the licenses to determine their meaning, this FAQ 91 entry is not intended to change the meaning or terms of the licenses. 92 </para> 93 </answer> 94 </qandaentry> 95 96 <qandaentry> 97 <question> 98 <para> 99 What is the difference between a bus name, and object path, 100 and an interface? 101 </para> 102 </question> 103 <answer> 104 <para> 105 If you imagine a C++ program that implements a network service, then 106 the bus name is the hostname of the computer running this C++ program, 107 the object path is a C++ object instance pointer, and an interface is 108 a C++ class (a pure virtual or abstract class, to be exact). 109 </para> 110 <para> 111 In Java terms, the object path is an object reference, 112 and an interface is a Java interface. 113 </para> 114 <para> 115 People get confused because if they write an application 116 with a single object instance and a single interface, 117 then the bus name, object path, and interface look 118 redundant. For example, you might have a text editor 119 that uses the bus name <literal>org.freedesktop.TextEditor</literal>, 120 has a global singleton object called 121 <literal>/org/freedesktop/TextEditor</literal>, and 122 that singleton object could implement the interface 123 <literal>org.freedesktop.TextEditor</literal>. 124 </para> 125 <para> 126 However, a text editor application could as easily own multiple bus 127 names (for example, <literal>org.kde.KWrite</literal> in addition to 128 generic <literal>TextEditor</literal>), have multiple objects (maybe 129 <literal>/org/kde/documents/4352</literal> where the number changes 130 according to the document), and each object could implement multiple 131 interfaces, such as <literal>org.freedesktop.DBus.Introspectable</literal>, 132 <literal>org.freedesktop.BasicTextField</literal>, 133 <literal>org.kde.RichTextDocument</literal>. 134 </para> 135 </answer> 136 </qandaentry> 137 138 139 <qandaentry id="service"> 140 <question> 141 <para> 142 What is a "service"? 143 </para> 144 </question> 145 <answer> 146 <para> 147 A service is a program that can be launched by the bus daemon 148 to provide some functionality to other programs. Services 149 are normally launched according to the bus name they will 150 have. 151 </para> 152 <para> 153 People often misuse the word "service" for any 154 bus name, but this tends to be ambiguous and confusing so is discouraged. 155 In the D-Bus docs we try to use "service" only when talking about 156 programs the bus knows how to launch, i.e. a service always has a 157 .service file. 158 </para> 159 </answer> 160 </qandaentry> 161 162 <qandaentry id="components"> 163 <question> 164 <para> 165 Is D-Bus a "component system"? 166 </para> 167 </question> 168 <answer> 169 <para> 170 It helps to keep these concepts separate in your mind: 171 <orderedlist> 172 <listitem> 173 <para> 174 Object/component system 175 </para> 176 </listitem> 177 <listitem> 178 <para> 179 GUI control/widget embedding interfaces 180 </para> 181 </listitem> 182 <listitem> 183 <para> 184 Interprocess communication system or wire protocol 185 </para> 186 </listitem> 187 </orderedlist> 188 </para> 189 <para> 190 D-Bus is not a component system. "Component system" was originally 191 defined by COM, and was essentially a workaround for the limitations 192 of the C++ object system (adding introspection, runtime location of 193 objects, ABI guarantees, and so forth). With the C# language and CLR, 194 Microsoft added these features to the primary object system, leaving 195 COM obsolete. Similarly, Java has much less need for something like 196 COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer 197 some of the same features found in COM. 198 </para> 199 <para> 200 Component systems are not about GUI control embedding. Embedding 201 a spreadsheet in a word processor document is a matter of defining 202 some specific <emphasis>interfaces</emphasis> that objects 203 can implement. These interfaces provide methods related to 204 GUI controls. So an object implementing those interfaces 205 can be embedded. 206 </para> 207 <para> 208 The word "component" just means "object with some fancy features" and 209 in modern languages all objects are effectively "components." 210 </para> 211 <para> 212 So components are fancy objects, and some objects are GUI controls. 213 </para> 214 <para> 215 A third, unrelated feature is interprocess communication or IPC. 216 D-Bus is an IPC system. Given an object (or "component" if you must), 217 you can expose the functionality of that object over an IPC system. 218 Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus. 219 You can use any of these IPC systems with any object/component system, 220 though some of them are "tuned" for specific object systems. 221 You can think of an IPC system primarily as a wire protocol. 222 </para> 223 <para> 224 If you combine an IPC system with a set of GUI control interfaces, 225 then you can have an out-of-process or dynamically-loaded GUI control. 226 </para> 227 <para> 228 Another related concept is the <firstterm>plugin</firstterm> or 229 <firstterm>extension</firstterm>. Generic plugin systems such as the 230 <ulink url="http://eclipse.org">Eclipse</ulink> system are not so different 231 from component/object systems, though perhaps a "plugin" tends to be a 232 bundle of objects with a user-visible name and can be 233 downloaded/packaged as a unit. 234 </para> 235 </answer> 236 </qandaentry> 237 238 <qandaentry id="speed"> 239 <question> 240 <para> 241 How fast is the D-Bus reference implementation? 242 </para> 243 </question> 244 <answer> 245 <para> 246 Of course it depends a bit on what you're doing. 247 <ulink url="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html"> 248 This mail</ulink> contains some benchmarking. At the time of that 249 benchmark, D-Bus one-to-one communication was about 2.5x slower than 250 simply pushing the data raw over a socket. After the recent rewrite of 251 the marshaling code, D-Bus is slower than that because a lot of 252 optimization work was lost. But it can probably be sped up again. 253 </para> 254 <para> 255 D-Bus communication with the intermediate bus daemon should be 256 (and as last profiled, was) about twice as slow as one-to-one 257 mode, because a round trip involves four socket reads/writes rather 258 than two socket reads/writes. 259 </para> 260 <para> 261 The overhead comes from a couple of places; part of it is simply 262 "abstraction penalty" (there are layers of code to support 263 multiple main loops, multiple transport types, security, etc.). 264 Probably the largest part comes from data validation 265 (because the reference implementation does not trust incoming data). 266 It would be simple to add a "no validation" mode, but probably 267 not a good idea all things considered. 268 </para> 269 <para> 270 Raw bandwidth isn't the only concern; D-Bus is designed to 271 enable asynchronous communication and avoid round trips. 272 This is frequently a more important performance issue 273 than throughput. 274 </para> 275 </answer> 276 </qandaentry> 277 278 279 <qandaentry id="size"> 280 <question> 281 <para> 282 How large is the D-Bus reference implementation? 283 </para> 284 </question> 285 <answer> 286 <para> 287 A production build (with assertions, unit tests, and verbose logging 288 disabled) is on the order of a 150K shared library. 289 </para> 290 <para> 291 A much, much smaller implementation would be possible by omitting out 292 of memory handling, hardcoding a main loop (or always using blocking 293 I/O), skipping validation, and otherwise simplifying things. 294 </para> 295 </answer> 296 </qandaentry> 297 298 <qandaentry id="other-ipc"> 299 <question> 300 <para> 301 How does D-Bus differ from other interprocess communication 302 or networking protocols? 303 </para> 304 </question> 305 <answer> 306 <para> 307 Keep in mind, it is not only an IPC system; it also includes 308 lifecycle tracking, service activation, security policy, and other 309 higher-level structure and assumptions. 310 </para> 311 <para> 312 The best place to start is to read the D-Bus <ulink url="dbus-tutorial.html">tutorial</ulink>, so 313 you have a concrete idea what D-Bus actually is. If you 314 understand other protocols on a wire format level, you 315 may also want to read the D-Bus <ulink url="dbus-specification.html">specification</ulink> to see what 316 D-Bus looks like on a low level. 317 </para> 318 <para> 319 As the <ulink url="dbus-tutorial.html">tutorial</ulink> and <ulink url="dbus-specification.html">specification</ulink> both explain, D-Bus is tuned 320 for some specific use cases. Thus, it probably isn't tuned 321 for what you want to do, unless you are doing the things 322 D-Bus was designed for. Don't make the mistake of thinking 323 that any system involving "IPC" is the same thing. 324 </para> 325 <para> 326 The D-Bus authors would not recommend using D-Bus 327 for applications where it doesn't make sense. 328 The following questions compare D-Bus to some other 329 protocols primarily to help you understand D-Bus 330 and decide whether it's appropriate; D-Bus is neither intended 331 nor claimed to be the right choice for every application. 332 </para> 333 <para> 334 It should be possible to bridge D-Bus to other IPC systems, 335 just as D-Bus can be bridged to object systems. 336 </para> 337 <para> 338 Note: the D-Bus mailing list subscribers are <emphasis>very much not 339 interested</emphasis> in debating which IPC system is the One True 340 System. So if you want to discuss that, please use another forum. 341 </para> 342 </answer> 343 </qandaentry> 344 345 346 <qandaentry id="corba"> 347 <question> 348 <para> 349 How does D-Bus differ from CORBA? 350 </para> 351 </question> 352 <answer> 353 <para> 354 Start by reading <xref linkend="other-ipc"/>. 355 </para> 356 <para> 357 <ulink url="http://www.omg.org">CORBA</ulink> is designed to support 358 object-oriented IPC between objects, automatically marshalling 359 parameters as necessary. CORBA is strongly supported by the <ulink 360 url="http://www.omg.org">Open Management Group (OMG)</ulink>, which 361 produces various standards and supporting documents for CORBA and has 362 the backing of many large organizations. There are many CORBA ORBs 363 available, both proprietary ORBs and free / open source software ORBs 364 (the latter include <ulink 365 url="http://orbit-resource.sourceforge.net/">ORBit</ulink>, <ulink 366 url="http://www.mico.org/">MICO</ulink>, and <ulink 367 url="http://www.theaceorb.com/">The ACE Orb (TAO)</ulink>). Many 368 organizations continue to use CORBA ORBs for various kinds of IPC. 369 </para> 370 <para> 371 Both GNOME and KDE have used CORBA and then moved away from it. KDE 372 had more success with a system called DCOP, and GNOME layered a system 373 called Bonobo on top of CORBA. Without custom extensions, CORBA does 374 not support many of the things one wants to do in a desktop 375 environment with the GNOME/KDE architecture. 376 </para> 377 <para> 378 CORBA on the other hand has a number of features of interest for 379 enterprise and web application development, though XML systems such as 380 SOAP are the latest fad. 381 </para> 382 <para> 383 Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems 384 work in terms of objects and methods, and have concepts such as 385 "oneway" calls. Only D-Bus has direct support for "signals" as in 386 GLib/Qt (or Java listeners, or C# delegates). 387 </para> 388 <para> 389 D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, 390 because CORBA is more generic and D-Bus has two specific use-cases in mind. 391 This makes D-Bus a bit simpler. 392 </para> 393 <para> 394 However, unlike CORBA D-Bus does <emphasis>not</emphasis> specify the 395 API for the language bindings. Instead, "native" bindings adapted 396 specifically to the conventions of a framework such as QObject, 397 GObject, C#, Java, Python, etc. are encouraged. The libdbus reference 398 implementation is designed to be a backend for bindings of this 399 nature, rather than to be used directly. The rationale is that an IPC 400 system API should not "leak" all over a program; it should come into 401 play only just before data goes over the wire. As an aside, OMG is 402 apparently working on a simpler C++ binding for CORBA. 403 </para> 404 <para> 405 Many CORBA implementations such as ORBit are faster than the libdbus 406 reference implementation. One reason is that D-Bus considers data 407 from the other end of the connection to be untrusted and extensively 408 validates it. But generally speaking other priorities were placed 409 ahead of raw speed in the libdbus implementation. A fast D-Bus 410 implementation along the lines of ORBit should be possible, of course. 411 </para> 412 <para> 413 On a more trivial note, D-Bus involves substantially fewer acronyms 414 than CORBA. 415 </para> 416 </answer> 417 </qandaentry> 418 419 420 <qandaentry id="xmlrpcsoap"> 421 <question> 422 <para> 423 How does D-Bus differ from XML-RPC and SOAP? 424 </para> 425 </question> 426 <answer> 427 <para> 428 Start by reading <xref linkend="other-ipc"/>. 429 </para> 430 <para> 431 In <ulink url="http://www.w3.org/TR/SOAP/">SOAP</ulink> and <ulink 432 url="http://www.xmlrpc.com">XML-RPC</ulink>, RPC calls are transformed 433 into an XML-based format, then sent over the wire (typically using the 434 HTTP protocol), where they are processed and returned. XML-RPC is the 435 simple protocol (its spec is only a page or two), and SOAP is the 436 full-featured protocol. 437 </para> 438 <para> 439 XML-RPC and SOAP impose XML parsing overhead that is normally 440 irrelevant in the context of the Internet, but significant for 441 constant fine-grained IPC among applications in a desktop session. 442 </para> 443 <para> 444 D-Bus offers persistent connections and with the bus daemon 445 supports lifecycle tracking of other applications connected 446 to the bus. With XML-RPC and SOAP, typically each method call 447 exists in isolation and has its own HTTP connection. 448 </para> 449 </answer> 450 </qandaentry> 451 452 <qandaentry id="dce"> 453 <question> 454 <para> 455 How does D-Bus differ from DCE? 456 </para> 457 </question> 458 <answer> 459 <para> 460 Start by reading <xref linkend="other-ipc"/>. 461 </para> 462 <para> 463 <ulink url="http://www.opengroup.org/dce/">Distributed Computing 464 Environment (DCE)</ulink> is an industry-standard vendor-neutral 465 standard that includes an IPC mechanism. <ulink 466 url="http://www.opengroup.org/comm/press/05-01-12.htm">The Open Group 467 has released an implementation as open source software</ulink>. DCE 468 is quite capable, and includes a vast amount of functionality such as 469 a distributed time service. As the name implies, DCE is intended for 470 use in a large, multi-computer distributed application. D-Bus would 471 not be well-suited for this. 472 </para> 473 </answer> 474 </qandaentry> 475 476 477 <qandaentry id="dcom"> 478 <question> 479 <para> 480 How does D-Bus differ from DCOM and COM? 481 </para> 482 </question> 483 <answer> 484 <para> 485 Start by reading <xref linkend="other-ipc"/>. 486 </para> 487 <para> 488 Comparing D-Bus to COM is apples and oranges; 489 see <xref linkend="components"/>. 490 </para> 491 <para> 492 DCOM (distributed COM) is a Windows IPC system designed for use with 493 the COM object system. It's similar in some ways to DCE and CORBA. 494 </para> 495 </answer> 496 </qandaentry> 497 498 <qandaentry id="internet-communications-engine"> 499 <question> 500 <para> 501 How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) 502 </para> 503 </question> 504 <answer> 505 <para> 506 Start by reading <xref linkend="other-ipc"/>. 507 </para> 508 <para> 509 The <ulink url="http://www.zeroc.com/ice.html"> Internet 510 Communications Engine (Ice)</ulink> is a powerful IPC mechanism more 511 on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license" 512 business around it; i.e. you can use it under the GPL, or pay for a 513 proprietary license. 514 </para> 515 </answer> 516 </qandaentry> 517 518 <qandaentry id="inter-client-exchange"> 519 <question> 520 <para> 521 How does D-Bus differ from Inter-Client Exchange (ICE)? 522 </para> 523 </question> 524 <answer> 525 <para> 526 <ulink url="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf">ICE</ulink> 527 was developed for the X Session Management protocol (XSMP), as part of 528 the X Window System (X11R6.1). The idea was to allow desktop sessions 529 to contain nongraphical clients in addition to X clients. 530 </para> 531 <para> 532 ICE is a binary protocol designed for desktop use, and KDE's DCOP 533 builds on ICE. ICE is substantially simpler than D-Bus (in contrast 534 to most of the other IPC systems mentioned here, which are more 535 complex). ICE doesn't really define a mapping to objects and methods 536 (DCOP adds that layer). The reference implementation of ICE (libICE) 537 is often considered to be horrible (and horribly insecure). 538 </para> 539 <para> 540 DCOP and XSMP are the only two widely-used applications of ICE, 541 and both could in principle be replaced by D-Bus. (Though whether 542 GNOME and KDE will bother is an open question.) 543 </para> 544 </answer> 545 </qandaentry> 546 547 548 549 <qandaentry id="dcop"> 550 <question> 551 <para> 552 How does D-Bus differ from DCOP? 553 </para> 554 </question> 555 <answer> 556 <para> 557 Start by reading <xref linkend="other-ipc"/>. 558 </para> 559 <para> 560 D-Bus is intentionally pretty similar to <ulink 561 url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP</ulink>, 562 and can be thought of as a "DCOP the next generation" suitable for 563 sharing between the various open source desktop projects. 564 </para> 565 <para> 566 D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus 567 should not be more complex for programmers. The additional complexity 568 of D-Bus arises from its separation of object references vs. bus names 569 vs. interfaces as distinct concepts, and its support for one-to-one 570 connections in addition to connections over the bus. The libdbus 571 reference implementation has a lot of API to support multiple bindings 572 and main loops, and performs data validation and out-of-memory handling 573 in order to support secure applications such as the systemwide bus. 574 </para> 575 <para> 576 D-Bus is probably somewhat slower than DCOP due to data validation 577 and more "layers" in the reference implementation. A comparison 578 hasn't been posted to the list though. 579 </para> 580 <para> 581 At this time, KDE has not committed to using D-Bus, but there have 582 been discussions of KDE bridging D-Bus and DCOP, or even changing 583 DCOP's implementation to use D-Bus internally (so that GNOME and KDE 584 would end up using exactly the same bus). See the KDE mailing list 585 archives for some of these discussions. 586 </para> 587 </answer> 588 </qandaentry> 589 590 591 <qandaentry id="yet-more-ipc"> 592 <question> 593 <para> 594 How does D-Bus differ from [yet more IPC mechanisms]? 595 </para> 596 </question> 597 <answer> 598 <para> 599 Start by reading <xref linkend="other-ipc"/>. 600 </para> 601 <para> 602 There are countless uses of network sockets in the world. <ulink 603 url="http://www.mbus.org/">MBUS</ulink>, Sun ONC/RPC, Jabber/XMPP, 604 SIP, are some we can think of quickly. 605 </para> 606 </answer> 607 </qandaentry> 608 609 610 <qandaentry id="which-ipc"> 611 <question> 612 <para> 613 Which IPC mechanism should I use? 614 </para> 615 </question> 616 <answer> 617 <para> 618 Start by reading <xref linkend="other-ipc"/>. 619 </para> 620 <para> 621 If you're writing an Internet or Intranet application, XML-RPC or SOAP 622 work for many people. These are standard, available for most 623 languages, simple to debug and easy to use. 624 </para> 625 <para> 626 If you're writing a desktop application for UNIX, 627 then D-Bus is of course our recommendation for 628 talking to other parts of the desktop session. 629 </para> 630 <para> 631 D-Bus is also designed for communications between system daemons and 632 communications between the desktop and system daemons. 633 </para> 634 <para> 635 If you're doing something complicated such as clustering, 636 distributed swarms, peer-to-peer, or whatever then 637 the authors of this FAQ don't have expertise in these 638 areas and you should ask someone else or try a search engine. 639 D-Bus is most likely a poor choice but could be appropriate 640 for some things. 641 </para> 642 <para> 643 Note: the D-Bus mailing list is probably not the place to 644 discuss which system is appropriate for your application, 645 though you are welcome to ask specific questions about 646 D-Bus <emphasis>after reading this FAQ, the tutorial, and 647 searching the list archives</emphasis>. The best way 648 to search the list archives is probably to use 649 an Internet engine such as Google. On Google, 650 include "site:freedesktop.org" in your search. 651 </para> 652 </answer> 653 </qandaentry> 654 655 656 <qandaentry> 657 <question> 658 <para> 659 How can I submit a bug or patch? 660 </para> 661 </question> 662 <answer> 663 <para> 664 The D-Bus <ulink url="http://dbus.freedesktop.org">web site</ulink> 665 has a link to the bug tracker, which is the best place to store 666 patches. You can also post them to the list, especially if you want 667 to discuss the patch or get feedback. 668 </para> 669 </answer> 670 </qandaentry> 671 672 </qandaset> 673 674 </article> 675
