* s/D-BUS/D-Bus/g

1 files changed, 66 insertions, 66 deletions

diff --git a/doc/dbus-faq.xml b/doc/dbus-faq.xml
index a233a212..963db366 100644
--- a/doc/dbus-faq.xml
+++ b/doc/dbus-faq.xml
@@ -6,7 +6,7 @@
 
 <article id="index">
   <articleinfo>
-    <title>D-BUS FAQ</title>
+    <title>D-Bus FAQ</title>
     <releaseinfo>Version 0.1</releaseinfo>
     <date>22 January 2005</date>
     <authorgroup>
@@ -33,12 +33,12 @@
     <qandaentry>
       <question>
         <para>
-          What is D-BUS?
+          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>. In
+          This is probably best answered by reading the D-Bus <ulink url="dbus-tutorial.html">tutorial</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.
@@ -49,12 +49,12 @@
     <qandaentry>
       <question>
         <para>
-          Is D-BUS stable/finished?
+          Is D-Bus stable/finished?
         </para>
       </question>
       <answer>
         <para>
-          D-BUS has not yet reached 1.0. The <ulink url="README">README</ulink>
+          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.
@@ -80,8 +80,8 @@
           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
+          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>
@@ -150,12 +150,12 @@
     <qandaentry id="components">
       <question>
         <para>
-          Is D-BUS a "component system"?
+          Is D-Bus a "component system"?
         </para>
       </question>
       <answer>
         <para>
-          D-BUS is not a component system. "Component system" was originally
+          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,
@@ -178,9 +178,9 @@
         </para>
         <para>
           A third, orthogonal feature is interprocess communication or IPC.
-          D-BUS is an IPC system. Given an object (or "component" if you must), 
+          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.
+          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.
@@ -223,7 +223,7 @@
     <qandaentry id="speed">
       <question>
         <para>
-          How fast is the D-BUS reference implementation?
+          How fast is the D-Bus reference implementation?
         </para>
       </question>
       <answer>
@@ -231,13 +231,13 @@
           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
+          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
+          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 
+          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.
@@ -252,7 +252,7 @@
           not a good idea all things considered.
         </para>
         <para>
-          Raw bandwidth isn't the only concern; D-BUS is designed to 
+          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.
@@ -264,7 +264,7 @@
     <qandaentry id="size">
       <question>
         <para>
-          How large is the D-BUS reference implementation?
+          How large is the D-Bus reference implementation?
         </para>
       </question>
       <answer>
@@ -283,39 +283,39 @@
     <qandaentry id="other-ipc">
       <question>
         <para>
-          How does D-BUS differ from other interprocess communication
+          How does D-Bus differ from other interprocess communication
           or networking protocols?
         </para>
       </question>
       <answer>
         <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 
+          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.
+          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 
+          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 
+          D-Bus was designed for. Don't make the mistake of thinking 
           that any system labeled "IPC" is the same thing.
         </para>
         <para>
-          The D-BUS authors would not recommend using D-BUS 
+          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
+          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.
+          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
+          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>
@@ -326,7 +326,7 @@
     <qandaentry id="corba">
       <question>
         <para>
-          How does D-BUS differ from CORBA?
+          How does D-Bus differ from CORBA?
         </para>
       </question>
       <answer>
@@ -360,18 +360,18 @@
           SOAP are the latest fad.
         </para>
         <para>
-          Like D-BUS, CORBA uses a fast binary protocol (IIOP). Both systems
+          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
+          "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.
+          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
+          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
@@ -383,14 +383,14 @@
         </para>
         <para>
           Many CORBA implementations such as ORBit are faster than the libdbus
-          reference implementation.  One reason is that D-BUS considers data
+          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
+          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
+          On a more trivial note, D-Bus involves substantially fewer acronyms
           than CORBA.
         </para>
       </answer>
@@ -400,7 +400,7 @@
     <qandaentry id="xmlrpcsoap">
       <question>
         <para>
-          How does D-BUS differ from XML-RPC and SOAP?
+          How does D-Bus differ from XML-RPC and SOAP?
         </para>
       </question>
       <answer>
@@ -421,7 +421,7 @@
           constant fine-grained IPC among applications in a desktop session.
         </para>
         <para>
-          D-BUS offers persistent connections and with the bus daemon 
+          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.
@@ -432,7 +432,7 @@
     <qandaentry id="dce">
       <question>
         <para>
-          How does D-BUS differ from DCE?
+          How does D-Bus differ from DCE?
         </para>
       </question>
       <answer>
@@ -447,7 +447,7 @@
           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
+          use in a large, multi-computer distributed application. D-Bus would
           not be well-suited for this.
         </para>
       </answer>
@@ -457,7 +457,7 @@
     <qandaentry id="dcom">
       <question>
         <para>
-          How does D-BUS differ from DCOM and COM?
+          How does D-Bus differ from DCOM and COM?
         </para>
       </question>
       <answer>
@@ -465,7 +465,7 @@
           Start by reading <xref linkend="other-ipc"/>.
         </para>
         <para>
-          Comparing D-BUS to COM is apples and oranges; 
+          Comparing D-Bus to COM is apples and oranges; 
           see <xref linkend="components"/>.
         </para>
         <para>
@@ -478,7 +478,7 @@
     <qandaentry id="internet-communications-engine">
       <question>
         <para>
-          How does D-BUS differ from ZeroC's Internet Communications Engine (Ice)
+          How does D-Bus differ from ZeroC's Internet Communications Engine (Ice)
         </para>
       </question>
       <answer>
@@ -488,7 +488,7 @@
         <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"
+          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>
@@ -498,7 +498,7 @@
     <qandaentry id="inter-client-exchange">
       <question>
         <para>
-          How does D-BUS differ from Inter-Client Exchange (ICE)?
+          How does D-Bus differ from Inter-Client Exchange (ICE)?
         </para>
       </question>
       <answer>
@@ -510,7 +510,7 @@
         </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
+          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)
@@ -518,7 +518,7 @@
         </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 
+          and both could in principle be replaced by D-Bus. (Though whether 
           GNOME and KDE will bother is an open question.)
         </para>
       </answer>
@@ -529,7 +529,7 @@
     <qandaentry id="dcop">
       <question>
         <para>
-          How does D-BUS differ from DCOP?
+          How does D-Bus differ from DCOP?
         </para>
       </question>
       <answer>
@@ -537,15 +537,15 @@
           Start by reading <xref linkend="other-ipc"/>.
         </para>
         <para>
-          D-BUS is intentionally pretty similar to <ulink
+          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
+          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
+          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
@@ -553,14 +553,14 @@
           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 
+          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
+          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>
@@ -571,7 +571,7 @@
     <qandaentry id="yet-more-ipc">
       <question>
         <para>
-          How does D-BUS differ from [yet more IPC mechanisms]?
+          How does D-Bus differ from [yet more IPC mechanisms]?
         </para>
       </question>
       <answer>
@@ -604,10 +604,10 @@
         </para>
         <para>
           If you're writing a desktop application for UNIX, 
-          then D-BUS is of course our recommendation for 
+          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.)
+          of D-Bus; until we reach 1.0, there isn't a stable release.)
         </para>
         <para>
           If you're doing something complicated such as clustering, 
@@ -616,10 +616,10 @@
           areas and you should ask someone else or try a search engine.
         </para>
         <para>
-          Note: the D-BUS mailing list is probably not the place to 
+          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 
+          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, 
@@ -637,7 +637,7 @@
       </question>
       <answer>
         <para>
-          The D-BUS <ulink url="http://dbus.freedesktop.org">web site</ulink>
+          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.