diff options
| author | Simon McVittie <smcv@debian.org> | 2011-01-31 17:37:59 +0000 |
|---|---|---|
| committer | Simon McVittie <smcv@debian.org> | 2011-01-31 17:37:59 +0000 |
| commit | 24fbe571516161d48b499d587f9adb3e683dbf88 (patch) | |
| tree | 7d70909156dcf587d91f693b8e1216eb4e0465e1 /doc/dbus-faq.html | |
| parent | 9b72896b3730a9fceb961be28bb95762a7b4e9d6 (diff) | |
| download | dbus-24fbe571516161d48b499d587f9adb3e683dbf88.tar.gz | |
Imported Upstream version 1.2.24upstream/1.2.24
Diffstat (limited to 'doc/dbus-faq.html')
| -rw-r--r-- | doc/dbus-faq.html | 437 |
1 files changed, 437 insertions, 0 deletions
diff --git a/doc/dbus-faq.html b/doc/dbus-faq.html new file mode 100644 index 00000000..dff70fad --- /dev/null +++ b/doc/dbus-faq.html @@ -0,0 +1,437 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>D-Bus FAQ</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article" title="D-Bus FAQ"><div class="titlepage"><div><div><h2 class="title"><a name="index"></a>D-Bus FAQ</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Havoc</span> <span class="surname">Pennington</span></h3><div class="affiliation"><span class="orgname">Red Hat, Inc.<br></span><div class="address"><p><br> + <code class="email"><<a class="email" href="mailto:hp@pobox.com">hp@pobox.com</a>></code><br> + </p></div></div></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="othername">A</span> <span class="surname">Wheeler</span></h3></div></div></div><div><p class="releaseinfo">Version 0.3</p></div></div><hr></div><div class="qandaset" title="Frequently Asked Questions"><a name="faq"></a><dl><dt>1. <a href="#id319467"> + What is D-Bus? + </a></dt><dt>2. <a href="#id322828"> + Is D-Bus stable/finished? + </a></dt><dt>3. <a href="#id322854"> + How is the reference implementation licensed? Can I use it in + proprietary applications? + </a></dt><dt>4. <a href="#id319923"> + What is the difference between a bus name, and object path, + and an interface? + </a></dt><dt>5. <a href="#service"> + What is a "service"? + </a></dt><dt>6. <a href="#components"> + Is D-Bus a "component system"? + </a></dt><dt>7. <a href="#speed"> + How fast is the D-Bus reference implementation? + </a></dt><dt>8. <a href="#size"> + How large is the D-Bus reference implementation? + </a></dt><dt>9. <a href="#other-ipc"> + How does D-Bus differ from other interprocess communication + or networking protocols? + </a></dt><dt>10. <a href="#corba"> + How does D-Bus differ from CORBA? + </a></dt><dt>11. <a href="#xmlrpcsoap"> + How does D-Bus differ from XML-RPC and SOAP? + </a></dt><dt>12. <a href="#dce"> + How does D-Bus differ from DCE? + </a></dt><dt>13. <a href="#dcom"> + How does D-Bus differ from DCOM and COM? + </a></dt><dt>14. <a href="#internet-communications-engine"> + How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) + </a></dt><dt>15. <a href="#inter-client-exchange"> + How does D-Bus differ from Inter-Client Exchange (ICE)? + </a></dt><dt>16. <a href="#dcop"> + How does D-Bus differ from DCOP? + </a></dt><dt>17. <a href="#yet-more-ipc"> + How does D-Bus differ from [yet more IPC mechanisms]? + </a></dt><dt>18. <a href="#which-ipc"> + Which IPC mechanism should I use? + </a></dt><dt>19. <a href="#id359012"> + How can I submit a bug or patch? + </a></dt></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%"><col><tbody><tr class="question" title="1."><td align="left" valign="top"><a name="id319467"></a><a name="id322798"></a><p><b>1.</b></p></td><td align="left" valign="top"><p> + What is D-Bus? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + This is probably best answered by reading the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> or + the introduction to the <a class="ulink" href="dbus-specification.html" target="_top">specification</a>. In + short, it is a system consisting of 1) a wire protocol for exposing a + typical object-oriented language/framework to other applications; and + 2) a bus daemon that allows applications to find and monitor one another. + Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level + structure (lifecycle tracking, service activation, security policy) provided by two bus daemons, + one systemwide and one per-user-session. + </p></td></tr><tr class="question" title="2."><td align="left" valign="top"><a name="id322828"></a><a name="id322830"></a><p><b>2.</b></p></td><td align="left" valign="top"><p> + Is D-Bus stable/finished? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + The low-level library "libdbus" and the protocol specification are considered + ABI stable. The <a class="ulink" href="README" target="_top">README</a> + file has a discussion of the API/ABI stability guarantees. + Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each + have their own release schedules and degree of maturity, not linked to + the low-level library and bus daemon release. Check the project page for + the binding you're considering to understand that project's policies. + </p></td></tr><tr class="question" title="3."><td align="left" valign="top"><a name="id322854"></a><a name="id322856"></a><p><b>3.</b></p></td><td align="left" valign="top"><p> + How is the reference implementation licensed? Can I use it in + proprietary applications? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + The short answer is yes, you can use it in proprietary applications. + You should read the <a class="ulink" href="COPYING" target="_top">COPYING</a> file, which + offers you the choice of two licenses. These are the GPL and the + AFL. The GPL requires that your application be licensed under the GPL + as well. The AFL is an "X-style" or "BSD-style" license compatible + with proprietary licensing, but it does have some requirements; in + particular it prohibits you from filing a lawsuit alleging that the + D-Bus software infringes your patents <span class="emphasis"><em>while you continue to + use D-Bus</em></span>. If you're going to sue, you have to stop using + the software. Read the licenses to determine their meaning, this FAQ + entry is not intended to change the meaning or terms of the licenses. + </p></td></tr><tr class="question" title="4."><td align="left" valign="top"><a name="id319923"></a><a name="id319925"></a><p><b>4.</b></p></td><td align="left" valign="top"><p> + What is the difference between a bus name, and object path, + and an interface? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + If you imagine a C++ program that implements a network service, then + the bus name is the hostname of the computer running this C++ program, + the object path is a C++ object instance pointer, and an interface is + a C++ class (a pure virtual or abstract class, to be exact). + </p><p> + In Java terms, the object path is an object reference, + and an interface is a Java interface. + </p><p> + People get confused because if they write an application + with a single object instance and a single interface, + then the bus name, object path, and interface look + redundant. For example, you might have a text editor + that uses the bus name <code class="literal">org.freedesktop.TextEditor</code>, + has a global singleton object called + <code class="literal">/org/freedesktop/TextEditor</code>, and + that singleton object could implement the interface + <code class="literal">org.freedesktop.TextEditor</code>. + </p><p> + However, a text editor application could as easily own multiple bus + names (for example, <code class="literal">org.kde.KWrite</code> in addition to + generic <code class="literal">TextEditor</code>), have multiple objects (maybe + <code class="literal">/org/kde/documents/4352</code> where the number changes + according to the document), and each object could implement multiple + interfaces, such as <code class="literal">org.freedesktop.DBus.Introspectable</code>, + <code class="literal">org.freedesktop.BasicTextField</code>, + <code class="literal">org.kde.RichTextDocument</code>. + </p></td></tr><tr class="question" title="5."><td align="left" valign="top"><a name="service"></a><a name="id320018"></a><p><b>5.</b></p></td><td align="left" valign="top"><p> + What is a "service"? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + A service is a program that can be launched by the bus daemon + to provide some functionality to other programs. Services + are normally launched according to the bus name they will + have. + </p><p> + People often misuse the word "service" for any + bus name, but this tends to be ambiguous and confusing so is discouraged. + In the D-Bus docs we try to use "service" only when talking about + programs the bus knows how to launch, i.e. a service always has a + .service file. + </p></td></tr><tr class="question" title="6."><td align="left" valign="top"><a name="components"></a><a name="id320045"></a><p><b>6.</b></p></td><td align="left" valign="top"><p> + Is D-Bus a "component system"? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + It helps to keep these concepts separate in your mind: + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p> + Object/component system + </p></li><li class="listitem"><p> + GUI control/widget embedding interfaces + </p></li><li class="listitem"><p> + Interprocess communication system or wire protocol + </p></li></ol></div><p> + </p><p> + D-Bus is not a component system. "Component system" was originally + defined by COM, and was essentially a workaround for the limitations + of the C++ object system (adding introspection, runtime location of + objects, ABI guarantees, and so forth). With the C# language and CLR, + Microsoft added these features to the primary object system, leaving + COM obsolete. Similarly, Java has much less need for something like + COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer + some of the same features found in COM. + </p><p> + Component systems are not about GUI control embedding. Embedding + a spreadsheet in a word processor document is a matter of defining + some specific <span class="emphasis"><em>interfaces</em></span> that objects + can implement. These interfaces provide methods related to + GUI controls. So an object implementing those interfaces + can be embedded. + </p><p> + The word "component" just means "object with some fancy features" and + in modern languages all objects are effectively "components." + </p><p> + So components are fancy objects, and some objects are GUI controls. + </p><p> + A third, unrelated feature is interprocess communication or IPC. + D-Bus is an IPC system. Given an object (or "component" if you must), + you can expose the functionality of that object over an IPC system. + Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus. + You can use any of these IPC systems with any object/component system, + though some of them are "tuned" for specific object systems. + You can think of an IPC system primarily as a wire protocol. + </p><p> + If you combine an IPC system with a set of GUI control interfaces, + then you can have an out-of-process or dynamically-loaded GUI control. + </p><p> + Another related concept is the <em class="firstterm">plugin</em> or + <em class="firstterm">extension</em>. Generic plugin systems such as the + <a class="ulink" href="http://eclipse.org" target="_top">Eclipse</a> system are not so different + from component/object systems, though perhaps a "plugin" tends to be a + bundle of objects with a user-visible name and can be + downloaded/packaged as a unit. + </p></td></tr><tr class="question" title="7."><td align="left" valign="top"><a name="speed"></a><a name="id319564"></a><p><b>7.</b></p></td><td align="left" valign="top"><p> + How fast is the D-Bus reference implementation? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Of course it depends a bit on what you're doing. + <a class="ulink" href="http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html" target="_top"> + This mail</a> contains some benchmarking. At the time of that + benchmark, D-Bus one-to-one communication was about 2.5x slower than + simply pushing the data raw over a socket. After the recent rewrite of + the marshaling code, D-Bus is slower than that because a lot of + optimization work was lost. But it can probably be sped up again. + </p><p> + D-Bus communication with the intermediate bus daemon should be + (and as last profiled, was) about twice as slow as one-to-one + mode, because a round trip involves four socket reads/writes rather + than two socket reads/writes. + </p><p> + The overhead comes from a couple of places; part of it is simply + "abstraction penalty" (there are layers of code to support + multiple main loops, multiple transport types, security, etc.). + Probably the largest part comes from data validation + (because the reference implementation does not trust incoming data). + It would be simple to add a "no validation" mode, but probably + not a good idea all things considered. + </p><p> + Raw bandwidth isn't the only concern; D-Bus is designed to + enable asynchronous communication and avoid round trips. + This is frequently a more important performance issue + than throughput. + </p></td></tr><tr class="question" title="8."><td align="left" valign="top"><a name="size"></a><a name="id319610"></a><p><b>8.</b></p></td><td align="left" valign="top"><p> + How large is the D-Bus reference implementation? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + A production build (with assertions, unit tests, and verbose logging + disabled) is on the order of a 150K shared library. + </p><p> + A much, much smaller implementation would be possible by omitting out + of memory handling, hardcoding a main loop (or always using blocking + I/O), skipping validation, and otherwise simplifying things. + </p></td></tr><tr class="question" title="9."><td align="left" valign="top"><a name="other-ipc"></a><a name="id358326"></a><p><b>9.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from other interprocess communication + or networking protocols? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Keep in mind, it is not only an IPC system; it also includes + lifecycle tracking, service activation, security policy, and other + higher-level structure and assumptions. + </p><p> + The best place to start is to read the D-Bus <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a>, so + you have a concrete idea what D-Bus actually is. If you + understand other protocols on a wire format level, you + may also want to read the D-Bus <a class="ulink" href="dbus-specification.html" target="_top">specification</a> to see what + D-Bus looks like on a low level. + </p><p> + As the <a class="ulink" href="dbus-tutorial.html" target="_top">tutorial</a> and <a class="ulink" href="dbus-specification.html" target="_top">specification</a> both explain, D-Bus is tuned + for some specific use cases. Thus, it probably isn't tuned + for what you want to do, unless you are doing the things + D-Bus was designed for. Don't make the mistake of thinking + that any system involving "IPC" is the same thing. + </p><p> + The D-Bus authors would not recommend using D-Bus + for applications where it doesn't make sense. + The following questions compare D-Bus to some other + protocols primarily to help you understand D-Bus + and decide whether it's appropriate; D-Bus is neither intended + nor claimed to be the right choice for every application. + </p><p> + It should be possible to bridge D-Bus to other IPC systems, + just as D-Bus can be bridged to object systems. + </p><p> + Note: the D-Bus mailing list subscribers are <span class="emphasis"><em>very much not + interested</em></span> in debating which IPC system is the One True + System. So if you want to discuss that, please use another forum. + </p></td></tr><tr class="question" title="10."><td align="left" valign="top"><a name="corba"></a><a name="id358398"></a><p><b>10.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from CORBA? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + <a class="ulink" href="http://www.omg.org" target="_top">CORBA</a> is designed to support + object-oriented IPC between objects, automatically marshalling + parameters as necessary. CORBA is strongly supported by the <a class="ulink" href="http://www.omg.org" target="_top">Open Management Group (OMG)</a>, which + produces various standards and supporting documents for CORBA and has + the backing of many large organizations. There are many CORBA ORBs + available, both proprietary ORBs and free / open source software ORBs + (the latter include <a class="ulink" href="http://orbit-resource.sourceforge.net/" target="_top">ORBit</a>, <a class="ulink" href="http://www.mico.org/" target="_top">MICO</a>, and <a class="ulink" href="http://www.theaceorb.com/" target="_top">The ACE Orb (TAO)</a>). Many + organizations continue to use CORBA ORBs for various kinds of IPC. + </p><p> + Both GNOME and KDE have used CORBA and then moved away from it. KDE + had more success with a system called DCOP, and GNOME layered a system + called Bonobo on top of CORBA. Without custom extensions, CORBA does + not support many of the things one wants to do in a desktop + environment with the GNOME/KDE architecture. + </p><p> + CORBA on the other hand has a number of features of interest for + enterprise and web application development, though XML systems such as + SOAP are the latest fad. + </p><p> + Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems + work in terms of objects and methods, and have concepts such as + "oneway" calls. Only D-Bus has direct support for "signals" as in + GLib/Qt (or Java listeners, or C# delegates). + </p><p> + D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended, + because CORBA is more generic and D-Bus has two specific use-cases in mind. + This makes D-Bus a bit simpler. + </p><p> + However, unlike CORBA D-Bus does <span class="emphasis"><em>not</em></span> specify the + API for the language bindings. Instead, "native" bindings adapted + specifically to the conventions of a framework such as QObject, + GObject, C#, Java, Python, etc. are encouraged. The libdbus reference + implementation is designed to be a backend for bindings of this + nature, rather than to be used directly. The rationale is that an IPC + system API should not "leak" all over a program; it should come into + play only just before data goes over the wire. As an aside, OMG is + apparently working on a simpler C++ binding for CORBA. + </p><p> + Many CORBA implementations such as ORBit are faster than the libdbus + reference implementation. One reason is that D-Bus considers data + from the other end of the connection to be untrusted and extensively + validates it. But generally speaking other priorities were placed + ahead of raw speed in the libdbus implementation. A fast D-Bus + implementation along the lines of ORBit should be possible, of course. + </p><p> + On a more trivial note, D-Bus involves substantially fewer acronyms + than CORBA. + </p></td></tr><tr class="question" title="11."><td align="left" valign="top"><a name="xmlrpcsoap"></a><a name="id319108"></a><p><b>11.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from XML-RPC and SOAP? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + In <a class="ulink" href="http://www.w3.org/TR/SOAP/" target="_top">SOAP</a> and <a class="ulink" href="http://www.xmlrpc.com" target="_top">XML-RPC</a>, RPC calls are transformed + into an XML-based format, then sent over the wire (typically using the + HTTP protocol), where they are processed and returned. XML-RPC is the + simple protocol (its spec is only a page or two), and SOAP is the + full-featured protocol. + </p><p> + XML-RPC and SOAP impose XML parsing overhead that is normally + irrelevant in the context of the Internet, but significant for + constant fine-grained IPC among applications in a desktop session. + </p><p> + D-Bus offers persistent connections and with the bus daemon + supports lifecycle tracking of other applications connected + to the bus. With XML-RPC and SOAP, typically each method call + exists in isolation and has its own HTTP connection. + </p></td></tr><tr class="question" title="12."><td align="left" valign="top"><a name="dce"></a><a name="id358723"></a><p><b>12.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from DCE? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + <a class="ulink" href="http://www.opengroup.org/dce/" target="_top">Distributed Computing + Environment (DCE)</a> is an industry-standard vendor-neutral + standard that includes an IPC mechanism. <a class="ulink" href="http://www.opengroup.org/comm/press/05-01-12.htm" target="_top">The Open Group + has released an implementation as open source software</a>. DCE + is quite capable, and includes a vast amount of functionality such as + a distributed time service. As the name implies, DCE is intended for + use in a large, multi-computer distributed application. D-Bus would + not be well-suited for this. + </p></td></tr><tr class="question" title="13."><td align="left" valign="top"><a name="dcom"></a><a name="id358763"></a><p><b>13.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from DCOM and COM? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + Comparing D-Bus to COM is apples and oranges; + see <a class="xref" href="#components" title="6.">Q: 6</a>. + </p><p> + DCOM (distributed COM) is a Windows IPC system designed for use with + the COM object system. It's similar in some ways to DCE and CORBA. + </p></td></tr><tr class="question" title="14."><td align="left" valign="top"><a name="internet-communications-engine"></a><a name="id358799"></a><p><b>14.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from ZeroC's Internet Communications Engine (Ice) + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + The <a class="ulink" href="http://www.zeroc.com/ice.html" target="_top"> Internet + Communications Engine (Ice)</a> is a powerful IPC mechanism more + on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license" + business around it; i.e. you can use it under the GPL, or pay for a + proprietary license. + </p></td></tr><tr class="question" title="15."><td align="left" valign="top"><a name="inter-client-exchange"></a><a name="id358832"></a><p><b>15.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from Inter-Client Exchange (ICE)? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + <a class="ulink" href="http://www.x.org/X11R6.8.1/docs/ICE/ice.pdf" target="_top">ICE</a> + was developed for the X Session Management protocol (XSMP), as part of + the X Window System (X11R6.1). The idea was to allow desktop sessions + to contain nongraphical clients in addition to X clients. + </p><p> + ICE is a binary protocol designed for desktop use, and KDE's DCOP + builds on ICE. ICE is substantially simpler than D-Bus (in contrast + to most of the other IPC systems mentioned here, which are more + complex). ICE doesn't really define a mapping to objects and methods + (DCOP adds that layer). The reference implementation of ICE (libICE) + is often considered to be horrible (and horribly insecure). + </p><p> + DCOP and XSMP are the only two widely-used applications of ICE, + and both could in principle be replaced by D-Bus. (Though whether + GNOME and KDE will bother is an open question.) + </p></td></tr><tr class="question" title="16."><td align="left" valign="top"><a name="dcop"></a><a name="id358871"></a><p><b>16.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from DCOP? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + D-Bus is intentionally pretty similar to <a class="ulink" href="http://developer.kde.org/documentation/library/kdeqt/dcop.html" target="_top">DCOP</a>, + and can be thought of as a "DCOP the next generation" suitable for + sharing between the various open source desktop projects. + </p><p> + D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus + should not be more complex for programmers. The additional complexity + of D-Bus arises from its separation of object references vs. bus names + vs. interfaces as distinct concepts, and its support for one-to-one + connections in addition to connections over the bus. The libdbus + reference implementation has a lot of API to support multiple bindings + and main loops, and performs data validation and out-of-memory handling + in order to support secure applications such as the systemwide bus. + </p><p> + D-Bus is probably somewhat slower than DCOP due to data validation + and more "layers" in the reference implementation. A comparison + hasn't been posted to the list though. + </p><p> + At this time, KDE has not committed to using D-Bus, but there have + been discussions of KDE bridging D-Bus and DCOP, or even changing + DCOP's implementation to use D-Bus internally (so that GNOME and KDE + would end up using exactly the same bus). See the KDE mailing list + archives for some of these discussions. + </p></td></tr><tr class="question" title="17."><td align="left" valign="top"><a name="yet-more-ipc"></a><a name="id358929"></a><p><b>17.</b></p></td><td align="left" valign="top"><p> + How does D-Bus differ from [yet more IPC mechanisms]? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + There are countless uses of network sockets in the world. <a class="ulink" href="http://www.mbus.org/" target="_top">MBUS</a>, Sun ONC/RPC, Jabber/XMPP, + SIP, are some we can think of quickly. + </p></td></tr><tr class="question" title="18."><td align="left" valign="top"><a name="which-ipc"></a><a name="id358962"></a><p><b>18.</b></p></td><td align="left" valign="top"><p> + Which IPC mechanism should I use? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + Start by reading <a class="xref" href="#other-ipc" title="9.">Q: 9</a>. + </p><p> + If you're writing an Internet or Intranet application, XML-RPC or SOAP + work for many people. These are standard, available for most + languages, simple to debug and easy to use. + </p><p> + If you're writing a desktop application for UNIX, + then D-Bus is of course our recommendation for + talking to other parts of the desktop session. + </p><p> + D-Bus is also designed for communications between system daemons and + communications between the desktop and system daemons. + </p><p> + If you're doing something complicated such as clustering, + distributed swarms, peer-to-peer, or whatever then + the authors of this FAQ don't have expertise in these + areas and you should ask someone else or try a search engine. + D-Bus is most likely a poor choice but could be appropriate + for some things. + </p><p> + Note: the D-Bus mailing list is probably not the place to + discuss which system is appropriate for your application, + though you are welcome to ask specific questions about + D-Bus <span class="emphasis"><em>after reading this FAQ, the tutorial, and + searching the list archives</em></span>. The best way + to search the list archives is probably to use + an Internet engine such as Google. On Google, + include "site:freedesktop.org" in your search. + </p></td></tr><tr class="question" title="19."><td align="left" valign="top"><a name="id359012"></a><a name="id359014"></a><p><b>19.</b></p></td><td align="left" valign="top"><p> + How can I submit a bug or patch? + </p></td></tr><tr class="answer"><td align="left" valign="top"></td><td align="left" valign="top"><p> + The D-Bus <a class="ulink" href="http://dbus.freedesktop.org" target="_top">web site</a> + has a link to the bug tracker, which is the best place to store + patches. You can also post them to the list, especially if you want + to discuss the patch or get feedback. + </p></td></tr></tbody></table></div></div></body></html> |