| <?xml version="1.0" standalone="no"?> |
| <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" |
| "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" |
| [ |
| ]> |
| |
| <article id="index"> |
| <articleinfo> |
| <title>D-Bus FAQ</title> |
| <releaseinfo>Version 0.3</releaseinfo> |
| <date>17 November 2006</date> |
| <authorgroup> |
| <author> |
| <firstname>Havoc</firstname> |
| <surname>Pennington</surname> |
| <affiliation> |
| <orgname>Red Hat, Inc.</orgname> |
| <address> |
| <email>hp@pobox.com</email> |
| </address> |
| </affiliation> |
| </author> |
| <author> |
| <firstname>David</firstname> |
| <othername role="mi">A</othername> |
| <surname>Wheeler</surname> |
| </author> |
| </authorgroup> |
| </articleinfo> |
| |
| <qandaset id="faq"> |
| |
| <qandaentry> |
| <question> |
| <para> |
| What is D-Bus? |
| </para> |
| </question> |
| <answer> |
| <para> |
| This is probably best answered by reading the D-Bus <ulink url="dbus-tutorial.html">tutorial</ulink> or |
| the introduction to the <ulink url="dbus-specification.html">specification</ulink>. 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| Is D-Bus stable/finished? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The low-level library "libdbus" and the protocol specification are considered |
| ABI stable. The <ulink url="README">README</ulink> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| How is the reference implementation licensed? Can I use it in |
| proprietary applications? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The short answer is yes, you can use it in proprietary applications. |
| You should read the <ulink url="COPYING">COPYING</ulink> 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 <emphasis>while you continue to |
| use D-Bus</emphasis>. 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry> |
| <question> |
| <para> |
| What is the difference between a bus name, and object path, |
| and an interface? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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). |
| </para> |
| <para> |
| In Java terms, the object path is an object reference, |
| and an interface is a Java interface. |
| </para> |
| <para> |
| 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 <literal>org.freedesktop.TextEditor</literal>, |
| has a global singleton object called |
| <literal>/org/freedesktop/TextEditor</literal>, and |
| that singleton object could implement the interface |
| <literal>org.freedesktop.TextEditor</literal>. |
| </para> |
| <para> |
| However, a text editor application could as easily own multiple bus |
| names (for example, <literal>org.kde.KWrite</literal> in addition to |
| generic <literal>TextEditor</literal>), have multiple objects (maybe |
| <literal>/org/kde/documents/4352</literal> where the number changes |
| according to the document), and each object could implement multiple |
| interfaces, such as <literal>org.freedesktop.DBus.Introspectable</literal>, |
| <literal>org.freedesktop.BasicTextField</literal>, |
| <literal>org.kde.RichTextDocument</literal>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="service"> |
| <question> |
| <para> |
| What is a "service"? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="components"> |
| <question> |
| <para> |
| Is D-Bus a "component system"? |
| </para> |
| </question> |
| <answer> |
| <para> |
| It helps to keep these concepts separate in your mind: |
| <orderedlist> |
| <listitem> |
| <para> |
| Object/component system |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| GUI control/widget embedding interfaces |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| Interprocess communication system or wire protocol |
| </para> |
| </listitem> |
| </orderedlist> |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| Component systems are not about GUI control embedding. Embedding |
| a spreadsheet in a word processor document is a matter of defining |
| some specific <emphasis>interfaces</emphasis> that objects |
| can implement. These interfaces provide methods related to |
| GUI controls. So an object implementing those interfaces |
| can be embedded. |
| </para> |
| <para> |
| The word "component" just means "object with some fancy features" and |
| in modern languages all objects are effectively "components." |
| </para> |
| <para> |
| So components are fancy objects, and some objects are GUI controls. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| Another related concept is the <firstterm>plugin</firstterm> or |
| <firstterm>extension</firstterm>. Generic plugin systems such as the |
| <ulink url="http://eclipse.org">Eclipse</ulink> 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="speed"> |
| <question> |
| <para> |
| How fast is the D-Bus reference implementation? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Of course it depends a bit on what you're doing. |
| <ulink url="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html"> |
| This mail</ulink> 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="size"> |
| <question> |
| <para> |
| How large is the D-Bus reference implementation? |
| </para> |
| </question> |
| <answer> |
| <para> |
| A production build (with assertions, unit tests, and verbose logging |
| disabled) is on the order of a 150K shared library. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="other-ipc"> |
| <question> |
| <para> |
| How does D-Bus differ from other interprocess communication |
| or networking protocols? |
| </para> |
| </question> |
| <answer> |
| <para> |
| 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. |
| </para> |
| <para> |
| The best place to start is to read the D-Bus <ulink url="dbus-tutorial.html">tutorial</ulink>, 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 <ulink url="dbus-specification.html">specification</ulink> to see what |
| D-Bus looks like on a low level. |
| </para> |
| <para> |
| As the <ulink url="dbus-tutorial.html">tutorial</ulink> and <ulink url="dbus-specification.html">specification</ulink> 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| It should be possible to bridge D-Bus to other IPC systems, |
| just as D-Bus can be bridged to object systems. |
| </para> |
| <para> |
| Note: the D-Bus mailing list subscribers are <emphasis>very much not |
| interested</emphasis> in debating which IPC system is the One True |
| System. So if you want to discuss that, please use another forum. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="corba"> |
| <question> |
| <para> |
| How does D-Bus differ from CORBA? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| <ulink url="http://www.omg.org">CORBA</ulink> is designed to support |
| object-oriented IPC between objects, automatically marshalling |
| parameters as necessary. CORBA is strongly supported by the <ulink |
| url="http://www.omg.org">Open Management Group (OMG)</ulink>, which |
| produces various standards and supporting documents for CORBA and has |
| the backing of many large organizations. There are many CORBA ORBs |
| available, both proprietary ORBs and free / open source software ORBs |
| (the latter include <ulink |
| url="http://orbit-resource.sourceforge.net/">ORBit</ulink>, <ulink |
| url="http://www.mico.org/">MICO</ulink>, and <ulink |
| url="http://www.theaceorb.com/">The ACE Orb (TAO)</ulink>). Many |
| organizations continue to use CORBA ORBs for various kinds of IPC. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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). |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| However, unlike CORBA D-Bus does <emphasis>not</emphasis> 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| On a more trivial note, D-Bus involves substantially fewer acronyms |
| than CORBA. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="xmlrpcsoap"> |
| <question> |
| <para> |
| How does D-Bus differ from XML-RPC and SOAP? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| In <ulink url="http://www.w3.org/TR/SOAP/">SOAP</ulink> and <ulink |
| url="http://www.xmlrpc.com">XML-RPC</ulink>, RPC calls are transformed |
| into an XML-based format, then sent over the wire (typically using the |
| HTTP protocol), where they are processed and returned. XML-RPC is the |
| simple protocol (its spec is only a page or two), and SOAP is the |
| full-featured protocol. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="dce"> |
| <question> |
| <para> |
| How does D-Bus differ from DCE? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| <ulink url="http://www.opengroup.org/dce/">Distributed Computing |
| Environment (DCE)</ulink> is an industry-standard vendor-neutral |
| standard that includes an IPC mechanism. <ulink |
| url="http://www.opengroup.org/comm/press/05-01-12.htm">The Open Group |
| has released an implementation as open source software</ulink>. DCE |
| is quite capable, and includes a vast amount of functionality 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="dcom"> |
| <question> |
| <para> |
| How does D-Bus differ from DCOM and COM? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| Comparing D-Bus to COM is apples and oranges; |
| see <xref linkend="components"/>. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="internet-communications-engine"> |
| <question> |
| <para> |
| How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| The <ulink url="http://www.zeroc.com/ice.html"> Internet |
| Communications Engine (Ice)</ulink> 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry id="inter-client-exchange"> |
| <question> |
| <para> |
| How does D-Bus differ from Inter-Client Exchange (ICE)? |
| </para> |
| </question> |
| <answer> |
| <para> |
| <ulink url="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf">ICE</ulink> |
| 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. |
| </para> |
| <para> |
| 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). |
| </para> |
| <para> |
| 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.) |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| |
| <qandaentry id="dcop"> |
| <question> |
| <para> |
| How does D-Bus differ from DCOP? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| D-Bus is intentionally pretty similar to <ulink |
| url="http://developer.kde.org/documentation/library/kdeqt/dcop.html">DCOP</ulink>, |
| and can be thought of as a "DCOP the next generation" suitable for |
| sharing between the various open source desktop projects. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="yet-more-ipc"> |
| <question> |
| <para> |
| How does D-Bus differ from [yet more IPC mechanisms]? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| There are countless uses of network sockets in the world. <ulink |
| url="http://www.mbus.org/">MBUS</ulink>, Sun ONC/RPC, Jabber/XMPP, |
| SIP, are some we can think of quickly. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry id="which-ipc"> |
| <question> |
| <para> |
| Which IPC mechanism should I use? |
| </para> |
| </question> |
| <answer> |
| <para> |
| Start by reading <xref linkend="other-ipc"/>. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| D-Bus is also designed for communications between system daemons and |
| communications between the desktop and system daemons. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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 <emphasis>after reading this FAQ, the tutorial, and |
| searching the list archives</emphasis>. 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry> |
| <question> |
| <para> |
| How can I submit a bug or patch? |
| </para> |
| </question> |
| <answer> |
| <para> |
| The D-Bus <ulink url="http://dbus.freedesktop.org">web site</ulink> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandaset> |
| |
| </article> |
