jni/dbus/doc/dbus-faq.xml

<?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>