[rename] renamed kdbus related macros
[platform/upstream/dbus.git] / doc / dbus-faq.xml
index 47072e9..0d296d9 100644 (file)
@@ -1,14 +1,14 @@
 <?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"
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
 [
 ]>
 
 <article id="index">
   <articleinfo>
     <title>D-Bus FAQ</title>
-    <releaseinfo>Version 0.1</releaseinfo>
-    <date>22 January 2005</date>
+    <releaseinfo>Version 0.3</releaseinfo>
+    <date>17 November 2006</date>
     <authorgroup>
       <author>
        <firstname>Havoc</firstname>
       </question>
       <answer>
         <para>
-          This is probably best answered by reading the D-Bus <ulink url="dbus-tutorial.html">tutorial</ulink>. In
+          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>
       </question>
       <answer>
         <para>
-          D-Bus has not yet reached 1.0. The <ulink url="README">README</ulink>
-          file has a discussion of the API/ABI stability guarantees before and
-          after 1.0. In short, there are no guarantees before 1.0, and stability
-          of both protocol and reference library will be maintained after 1.0.
-          As of January 2005 we don't expect major protocol or API changes prior
-          to the 1.0 release, but anything is possible.
+          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>
           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>
 
       </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 
           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 labeled "IPC" is the same thing.
+          that any system involving "IPC" is the same thing.
         </para>
         <para>
           The D-Bus authors would not recommend using D-Bus 
           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.
-          (With the caveat that you should use a stable release 
-          of D-Bus; until we reach 1.0, there isn't a stable release.)
+        </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