dbus/doc dbus-faq.xml, 1.4, 1.5 dbus-specification.xml, 1.40,
1.41 dbus-test-plan.xml, 1.2, 1.3 dbus-tutorial.xml, 1.18,
1.19 introspect.dtd, 1.3, 1.4
John Palmieri
johnp at kemper.freedesktop.org
Thu Aug 3 13:34:38 PDT 2006
- Previous message: dbus COPYING, 1.5, 1.6 ChangeLog, 1.1059, 1.1060 Doxyfile.in, 1.10,
1.11 HACKING, 1.14, 1.15 configure.in, 1.159, 1.160
- Next message: dbus/tools dbus-cleanup-sockets.1, 1.1, 1.2 dbus-cleanup-sockets.c,
1.2, 1.3 dbus-launch.1, 1.5, 1.6 dbus-launch.c, 1.13,
1.14 dbus-monitor.1, 1.5, 1.6 dbus-send.1, 1.6,
1.7 dbus-send.c, 1.20, 1.21 dbus-viewer.c, 1.16, 1.17
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Update of /cvs/dbus/dbus/doc
In directory kemper:/tmp/cvs-serv22390/doc
Modified Files:
dbus-faq.xml dbus-specification.xml dbus-test-plan.xml
dbus-tutorial.xml introspect.dtd
Log Message:
* s/D-BUS/D-Bus/g
Index: dbus-faq.xml
===================================================================
RCS file: /cvs/dbus/dbus/doc/dbus-faq.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- dbus-faq.xml 17 Feb 2005 21:19:49 -0000 1.4
+++ dbus-faq.xml 3 Aug 2006 20:34:36 -0000 1.5
@@ -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.
Index: dbus-specification.xml
===================================================================
RCS file: /cvs/dbus/dbus/doc/dbus-specification.xml,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -d -r1.40 -r1.41
--- dbus-specification.xml 14 Jul 2006 01:17:59 -0000 1.40
+++ dbus-specification.xml 3 Aug 2006 20:34:36 -0000 1.41
@@ -6,7 +6,7 @@
<article id="index">
<articleinfo>
- <title>D-BUS Specification</title>
+ <title>D-Bus Specification</title>
<releaseinfo>Version 0.11</releaseinfo>
<date>6 February 2005</date>
<authorgroup>
@@ -46,30 +46,30 @@
<sect1 id="introduction">
<title>Introduction</title>
<para>
- D-BUS is a system for low-latency, low-overhead, easy to use
+ D-Bus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC). In more detail:
<itemizedlist>
<listitem>
<para>
- D-BUS is <emphasis>low-latency</emphasis> because it is designed
+ D-Bus is <emphasis>low-latency</emphasis> because it is designed
to avoid round trips and allow asynchronous operation, much like
the X protocol.
</para>
</listitem>
<listitem>
<para>
- D-BUS is <emphasis>low-overhead</emphasis> because it uses a
+ D-Bus is <emphasis>low-overhead</emphasis> because it uses a
binary protocol, and does not have to convert to and from a text
- format such as XML. Because D-BUS is intended for potentially
+ format such as XML. Because D-Bus is intended for potentially
high-resolution same-machine IPC, not primarily for Internet IPC,
this is an interesting optimization.
</para>
</listitem>
<listitem>
<para>
- D-BUS is <emphasis>easy to use</emphasis> because it works in terms
+ D-Bus is <emphasis>easy to use</emphasis> because it works in terms
of <firstterm>messages</firstterm> rather than byte streams, and
- automatically handles a lot of the hard IPC issues. Also, the D-BUS
+ automatically handles a lot of the hard IPC issues. Also, the D-Bus
library is designed to be wrapped in a way that lets developers use
their framework's existing object/type system, rather than learning
a new one specifically for IPC.
@@ -79,25 +79,25 @@
</para>
<para>
- The base D-BUS protocol is a one-to-one (peer-to-peer or client-server)
+ The base D-Bus protocol is a one-to-one (peer-to-peer or client-server)
protocol, specified in <xref linkend="message-protocol"/>. That is, it is
a system for one application to talk to a single other
application. However, the primary intended application of the protocol is the
- D-BUS <firstterm>message bus</firstterm>, specified in <xref
+ D-Bus <firstterm>message bus</firstterm>, specified in <xref
linkend="message-bus"/>. The message bus is a special application that
accepts connections from multiple other applications, and forwards
messages among them.
</para>
<para>
- Uses of D-BUS include notification of system changes (notification of when
+ Uses of D-Bus include notification of system changes (notification of when
a camera is plugged in to a computer, or a new version of some software
has been installed), or desktop interoperability, for example a file
monitoring service or a configuration service.
</para>
<para>
- D-BUS is designed for two specific use cases:
+ D-Bus is designed for two specific use cases:
<itemizedlist>
<listitem>
<para>
@@ -112,9 +112,9 @@
</para>
</listitem>
</itemizedlist>
- D-BUS is not intended to be a generic IPC system for any possible
+ D-Bus is not intended to be a generic IPC system for any possible
application, and intentionally omits many features found in other
- IPC systems for this reason. D-BUS may turn out to be useful
+ IPC systems for this reason. D-Bus may turn out to be useful
in unanticipated applications, but future versions of this
spec and the reference implementation probably will not
incorporate features that interfere with the core use cases.
@@ -160,7 +160,7 @@
<title>Type Signatures</title>
<para>
- The D-BUS protocol does not include type tags in the marshaled data; a
+ The D-Bus protocol does not include type tags in the marshaled data; a
block of marshaled values must have a known <firstterm>type
signature</firstterm>. The type signature is made up of <firstterm>type
codes</firstterm>. A type code is an ASCII character representing the
@@ -212,7 +212,7 @@
</para>
<para>
- The <literal>STRUCT</literal> type code 'r' is not currently used in the D-BUS protocol,
+ The <literal>STRUCT</literal> type code 'r' is not currently used in the D-Bus protocol,
but is useful in code that implements the protocol. This type code
is specified to allow such code to interoperate in non-protocol contexts.
</para>
@@ -296,7 +296,7 @@
</para>
<para>
- The following table summarizes the D-BUS types.
+ The following table summarizes the D-Bus types.
<informaltable>
<tgroup cols="3">
<thead>
@@ -389,12 +389,12 @@
<para>
Given a type signature, a block of bytes can be converted into typed
values. This section describes the format of the block of bytes. Byte
- order and alignment issues are handled uniformly for all D-BUS types.
+ order and alignment issues are handled uniformly for all D-Bus types.
</para>
<para>
A block of bytes has an associated byte order. The byte order
- has to be discovered in some way; for D-BUS messages, the
+ has to be discovered in some way; for D-Bus messages, the
byte order is part of the message header as described in
<xref linkend="message-protocol-messages"/>. For now, assume
that the byte order is known to be either little endian or big
@@ -550,7 +550,7 @@
<para>
An object path is a name used to refer to an object instance.
- Conceptually, each participant in a D-BUS message exchange may have
+ Conceptually, each participant in a D-Bus message exchange may have
any number of object instances (think of C++ or Java objects) and each
such instance will have a path. Like a filesystem, the object
instances in an application form a hierarchical tree.
@@ -721,7 +721,7 @@
<entry>Major protocol version of the sending application. If
the major protocol version of the receiving application does not
match, the applications will not be able to communicate and the
- D-BUS connection must be disconnected. The major protocol
+ D-Bus connection must be disconnected. The major protocol
version for this version of the specification is 0.
FIXME this field is stupid and pointless to put in
every message.
@@ -960,7 +960,7 @@
<sect2 id="message-protocol-names">
<title>Valid Names</title>
<para>
- The various names in D-BUS messages have some restrictions.
+ The various names in D-Bus messages have some restrictions.
</para>
<para>
There is a <firstterm>maximum name length</firstterm>
@@ -1129,16 +1129,16 @@
<sect4 id="message-protocol-types-method-apis">
<title>Mapping method calls to native APIs</title>
<para>
- APIs for D-BUS may map method calls to a method call in a specific
+ APIs for D-Bus may map method calls to a method call in a specific
programming language, such as C++, or may map a method call written
- in an IDL to a D-BUS message.
+ in an IDL to a D-Bus message.
</para>
<para>
In APIs of this nature, arguments to a method are often termed "in"
(which implies sent in the <literal>METHOD_CALL</literal>), or "out" (which implies
returned in the <literal>METHOD_RETURN</literal>). Some APIs such as CORBA also have
"inout" arguments, which are both sent and received, i.e. the caller
- passes in a value which is modified. Mapped to D-BUS, an "inout"
+ passes in a value which is modified. Mapped to D-Bus, an "inout"
argument is equivalent to an "in" argument, followed by an "out"
argument. You can't pass things "by reference" over the wire, so
"inout" is purely an illusion of the in-process API.
@@ -1159,14 +1159,14 @@
exceptions.
</para>
<para>
- In converting from native APIs to D-BUS, it is perhaps nice to
- map D-BUS naming conventions ("FooBar") to native conventions
+ In converting from native APIs to D-Bus, it is perhaps nice to
+ map D-Bus naming conventions ("FooBar") to native conventions
such as "fooBar" or "foo_bar" automatically. This is OK
as long as you can say that the native API is one that
- was specifically written for D-BUS. It makes the most sense
+ was specifically written for D-Bus. It makes the most sense
when writing object implementations that will be exported
- over the bus. Object proxies used to invoke remote D-BUS
- objects probably need the ability to call any D-BUS method,
+ over the bus. Object proxies used to invoke remote D-Bus
+ objects probably need the ability to call any D-Bus method,
and thus a magic name mapping like this could be a problem.
</para>
<para>
@@ -1256,7 +1256,7 @@
<title>Invalid Protocol and Spec Extensions</title>
<para>
- For security reasons, the D-BUS protocol should be strictly parsed and
+ For security reasons, the D-Bus protocol should be strictly parsed and
validated, with the exception of defined extension points. Any invalid
protocol or spec violations should result in immediately dropping the
connection without notice to the other end. Exceptions should be
@@ -1275,10 +1275,10 @@
</para>
<para>
- The following extension points are built in to D-BUS on purpose and must
+ The following extension points are built in to D-Bus on purpose and must
not be treated as invalid protocol. The extension points are intended
for use by future versions of this spec, they are not intended for third
- parties. At the moment, the only way a third party could extend D-BUS
+ parties. At the moment, the only way a third party could extend D-Bus
without breaking interoperability would be to introduce a way to negotiate new
feature support as part of the auth protocol, using EXTENSION_-prefixed
commands. There is not yet a standard way to negotiate features.
@@ -1432,12 +1432,12 @@
<para>
The first octet received by the client after the \r\n of the OK
command must be the first octet of the authenticated/encrypted
- stream of D-BUS messages.
+ stream of D-Bus messages.
</para>
<para>
The first octet received by the server after the \r\n of the BEGIN
command from the client must be the first octet of the
- authenticated/encrypted stream of D-BUS messages.
+ authenticated/encrypted stream of D-Bus messages.
</para>
</sect2>
<sect2 id="auth-command-cancel">
@@ -1471,7 +1471,7 @@
<para>
The first octet received by the server after the \r\n of the BEGIN
command from the client must be the first octet of the
- authenticated/encrypted stream of D-BUS messages.
+ authenticated/encrypted stream of D-Bus messages.
</para>
</sect2>
<sect2 id="auth-command-rejected">
@@ -1493,13 +1493,13 @@
<title>OK Command</title>
<para>
The OK command indicates that the client has been authenticated,
- and that further communication will be a stream of D-BUS messages
+ and that further communication will be a stream of D-Bus messages
(optionally encrypted, as negotiated) rather than this protocol.
</para>
<para>
The first octet received by the client after the \r\n of the OK
command must be the first octet of the authenticated/encrypted
- stream of D-BUS messages.
+ stream of D-Bus messages.
</para>
<para>
The client must respond to the OK command by sending a BEGIN
@@ -1531,12 +1531,12 @@
if only canceling/rejecting the authentication.
</para>
<para>
- If the D-BUS protocol changes incompatibly at some future time,
+ If the D-Bus protocol changes incompatibly at some future time,
applications implementing the new protocol would probably be able to
check for support of the new protocol by sending a new command and
receiving an ERROR from applications that don't understand it. Thus the
ERROR feature of the auth protocol is an escape hatch that lets us
- negotiate extensions or changes to the D-BUS protocol in the future.
+ negotiate extensions or changes to the D-Bus protocol in the future.
</para>
</sect2>
<sect2 id="auth-examples">
@@ -2016,7 +2016,7 @@
<title>Authentication mechanisms</title>
<para>
This section describes some new authentication mechanisms.
- D-BUS also allows any standard SASL mechanism of course.
+ D-Bus also allows any standard SASL mechanism of course.
</para>
<sect3 id="auth-mechanisms-sha">
<title>DBUS_COOKIE_SHA1</title>
@@ -2266,7 +2266,7 @@
<title>Naming Conventions</title>
<para>
- D-BUS namespaces are all lowercase and correspond to reversed domain
+ D-Bus namespaces are all lowercase and correspond to reversed domain
names, as with Java. e.g. "org.freedesktop"
</para>
<para>
@@ -2284,7 +2284,7 @@
<para>
See <xref linkend="message-protocol-types-notation"/> for details on
the notation used in this section. There are some standard interfaces
- that may be useful across various D-BUS applications.
+ that may be useful across various D-Bus applications.
</para>
<sect2 id="standard-interfaces-peer">
<title><literal>org.freedesktop.DBus.Peer</literal></title>
@@ -2961,7 +2961,7 @@
<para>
The following table describes the keys that can be used to create
a match rule:
- The following table summarizes the D-BUS types.
+ The following table summarizes the D-Bus types.
<informaltable>
<tgroup cols="3">
<thead>
@@ -3032,7 +3032,7 @@
<firstterm>service</firstterm>.
</para>
<para>
- With D-BUS, starting a service is normally done by name. That is,
+ With D-Bus, starting a service is normally done by name. That is,
applications ask the message bus to start some program that will own a
well-known name, such as <literal>org.freedesktop.TextEditor</literal>.
This implies a contract documented along with the name
@@ -3175,7 +3175,7 @@
<literal>unix:path=/var/run/dbus/system_bus_socket</literal>.
<footnote>
<para>
- The D-BUS reference implementation actually honors the
+ The D-Bus reference implementation actually honors the
<literal>$(localstatedir)</literal> configure option
for this address, on both client and server side.
</para>
@@ -3747,7 +3747,7 @@
<glossentry id="term-message"><glossterm>Message</glossterm>
<glossdef>
<para>
- A message is the atomic unit of communication via the D-BUS
+ A message is the atomic unit of communication via the D-Bus
protocol. It consists of a <firstterm>header</firstterm> and a
<firstterm>body</firstterm>; the body is made up of
<firstterm>arguments</firstterm>.
@@ -3772,7 +3772,7 @@
<para>
See <xref linkend="term-bus-name"/>. "Name" may
also be used to refer to some of the other names
- in D-BUS, such as interface names.
+ in D-Bus, such as interface names.
</para>
</glossdef>
</glossentry>
@@ -3803,7 +3803,7 @@
<para>
An application talking directly to another application, without going
through a message bus. One-to-one connections may be "peer to peer" or
- "client to server." The D-BUS protocol has no concept of client
+ "client to server." The D-Bus protocol has no concept of client
vs. server after a connection has authenticated; the flow of messages
is symmetrical (full duplex).
</para>
@@ -3813,7 +3813,7 @@
<glossentry id="term-path"><glossterm>Path</glossterm>
<glossdef>
<para>
- Object references (object names) in D-BUS are organized into a
+ Object references (object names) in D-Bus are organized into a
filesystem-style hierarchy, so each object is named by a path. As in
LDAP, there's no difference between "files" and "directories"; a path
can refer to an object, while still having child objects below it.
Index: dbus-test-plan.xml
===================================================================
RCS file: /cvs/dbus/dbus/doc/dbus-test-plan.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- dbus-test-plan.xml 17 May 2004 22:19:04 -0000 1.2
+++ dbus-test-plan.xml 3 Aug 2006 20:34:36 -0000 1.3
@@ -6,7 +6,7 @@
<article id="index">
<articleinfo>
- <title>D-BUS Test Plan</title>
+ <title>D-Bus Test Plan</title>
<date>14 February 2003</date>
<authorgroup>
<author>
@@ -22,7 +22,7 @@
<sect1 id="introduction">
<title>Introduction</title>
<para>
- This document tries to explain the details of the test plan for D-BUS
+ This document tries to explain the details of the test plan for D-Bus
</para>
<sect2 id="importance-of-testing">
<title>The importance of testing</title>
@@ -32,21 +32,21 @@
overall.
</para>
<para>
- D-BUS is a large and complex piece of software (about 25,000
+ D-Bus is a large and complex piece of software (about 25,000
lines of code for the client library, and 2,500 lines of code
for the bus daemon) and it's therefore important to try to make sure
that all parts of the software is functioning correctly.
</para>
<para>
- D-BUS can be built with support for testing by passing
+ D-Bus can be built with support for testing by passing
<literal>--enable-tests</literal>. to the configure script. It
is recommended that production systems build without testing
- since that reduces the D-BUS client library size.
+ since that reduces the D-Bus client library size.
</para>
</sect2>
</sect1>
<sect1 id="client-library">
- <title>Testing the D-BUS client library</title>
+ <title>Testing the D-Bus client library</title>
<para>
The tests for the client library consist of the dbus-test
program which is a unit test for all aspects of the client
@@ -56,7 +56,7 @@
<sect2 id="data-structures">
<title>Data Structures</title>
<para>
- The D-BUS client library consists of some data structures that
+ The D-Bus client library consists of some data structures that
are used internally; a linked list class, a hashtable class and
a string class. All aspects of those are tested by dbus-test.
</para>
@@ -64,15 +64,15 @@
<sect2 id="message-loader">
<title>Message loader</title>
<para>
- The message loader is the part of D-BUS that takes messages in
+ The message loader is the part of D-Bus that takes messages in
raw character form and parses them, turning them into DBusMessages.
</para>
<para>
- This is one of the parts of D-BUS that
+ This is one of the parts of D-Bus that
<emphasis>must</emphasis> be absolutely bug-free and
robust. The message loader should be able to handle invalid
and incomplete messages without crashing. Not doing so is a
- serious issue and can easily result in D-BUS being exploitable
+ serious issue and can easily result in D-Bus being exploitable
to DoS attacks.
</para>
<para>
@@ -101,7 +101,7 @@
</figure>
<para>
The file format of messages in string form is documented in
- the D-BUS Reference Manual.
+ the D-Bus Reference Manual.
</para>
<para>
The message test part of dbus-test is using the message
@@ -145,9 +145,9 @@
</sect2>
</sect1>
<sect1 id="daemon">
- <title>Testing the D-BUS bus daemon</title>
+ <title>Testing the D-Bus bus daemon</title>
<para>
- Since the D-BUS bus daemon is using the D-BUS client library it
+ Since the D-Bus bus daemon is using the D-Bus client library it
will benefit from all tests done on the client library, but
there is still the issue of testing client-server communication.
This is more complicated since it it may require another process
@@ -156,15 +156,15 @@
<sect2 id="debug-transport">
<title>The debug transport</title>
<para>
- In D-BUS, a <emphasis>transport</emphasis> is a class that
+ In D-Bus, a <emphasis>transport</emphasis> is a class that
handles sending and receiving raw data over a certain
- medium. The transport that is used most in D-BUS is the UNIX
+ medium. The transport that is used most in D-Bus is the UNIX
transport with sends and recevies data over a UNIX socket. A
transport that tunnels data through X11 client messages is
also under development.
</para>
<para>
- The D-BUS debug transport is a specialized transport that
+ The D-Bus debug transport is a specialized transport that
works in-process. This means that a client and server that
exists in the same process can talk to eachother without using
a socket.
@@ -174,7 +174,7 @@
<title>The bus-test program</title>
<para>
The bus-test program is a program that is used to test various
- parts of the D-BUS bus daemon; robustness and that it conforms
+ parts of the D-Bus bus daemon; robustness and that it conforms
to the specifications.
</para>
<para>
@@ -197,7 +197,7 @@
<sect2 id="oom-robustness">
<title>Out-Of-Memory robustness</title>
<para>
- Since D-BUS should be able to be used in embedded devices, and
+ Since D-Bus should be able to be used in embedded devices, and
also as a system service, it should be able to cope with
low-memory situations without exiting or crashing.
</para>
Index: dbus-tutorial.xml
===================================================================
RCS file: /cvs/dbus/dbus/doc/dbus-tutorial.xml,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -d -r1.18 -r1.19
--- dbus-tutorial.xml 19 Dec 2005 18:11:05 -0000 1.18
+++ dbus-tutorial.xml 3 Aug 2006 20:34:36 -0000 1.19
@@ -6,7 +6,7 @@
<article id="index">
<articleinfo>
- <title>D-BUS Tutorial</title>
+ <title>D-Bus Tutorial</title>
<releaseinfo>Version 0.4.1</releaseinfo>
<date>15 July 2005</date>
<authorgroup>
@@ -42,9 +42,9 @@
</articleinfo>
<sect1 id="whatis">
- <title>What is D-BUS?</title>
+ <title>What is D-Bus?</title>
<para>
- D-BUS is a system for <firstterm>interprocess communication</firstterm>
+ D-Bus is a system for <firstterm>interprocess communication</firstterm>
(IPC). Architecturally, it has several layers:
<itemizedlist>
@@ -68,7 +68,7 @@
application frameworks. For example, libdbus-glib and
libdbus-qt. There are also bindings to languages such as
Python. These wrapper libraries are the API most people should use,
- as they simplify the details of D-BUS programming. libdbus is
+ as they simplify the details of D-Bus programming. libdbus is
intended to be a low-level backend for the higher level bindings.
Much of the libdbus API is only useful for binding implementation.
</para>
@@ -77,7 +77,7 @@
</para>
<para>
- If you just want to use D-BUS and don't care how it works, jump directly
+ If you just want to use D-Bus and don't care how it works, jump directly
to <xref linkend="concepts"/>.
Otherwise, read on.
</para>
@@ -115,7 +115,7 @@
</para>
<sect2 id="uses">
- <title>D-BUS applications</title>
+ <title>D-Bus applications</title>
<para>
There are many, many technologies in the world that have "Inter-process
communication" or "networking" in their stated purpose: <ulink
@@ -129,7 +129,7 @@
url="http://www.zeroc.com/ice.html">Internet Communications Engine (ICE)</ulink>,
and probably hundreds more.
Each of these is tailored for particular kinds of application.
- D-BUS is designed for two specific cases:
+ D-Bus is designed for two specific cases:
<itemizedlist>
<listitem>
<para>
@@ -151,9 +151,9 @@
<para>
For the within-desktop-session use case, the GNOME and KDE desktops
have significant previous experience with different IPC solutions
- such as CORBA and DCOP. D-BUS is built on that experience and
+ such as CORBA and DCOP. D-Bus is built on that experience and
carefully tailored to meet the needs of these desktop projects
- in particular. D-BUS may or may not be appropriate for other
+ in particular. D-Bus may or may not be appropriate for other
applications; the FAQ has some comparisons to other IPC systems.
</para>
<para>
@@ -186,7 +186,7 @@
</blockquote>
</para>
<para>
- D-BUS may happen to be useful for purposes other than the one it was
+ D-Bus may happen to be useful for purposes other than the one it was
designed for. Its general properties that distinguish it from
other forms of IPC are:
<itemizedlist>
@@ -233,7 +233,7 @@
<title>Concepts</title>
<para>
Some basic concepts apply no matter what application framework you're
- using to write a D-BUS application. The exact code you write will be
+ using to write a D-Bus application. The exact code you write will be
different for GLib vs. Qt vs. Python applications, however.
</para>
@@ -246,10 +246,10 @@
<sect2 id="objects">
<title>Objects and Object Paths</title>
<para>
- Each application using D-BUS contains <firstterm>objects</firstterm>,
+ Each application using D-Bus contains <firstterm>objects</firstterm>,
which generally map to GObject, QObject, C++ objects, or Python objects
(but need not). An object is an <emphasis>instance</emphasis> rather
- than a type. When messages are received over a D-BUS connection, they
+ than a type. When messages are received over a D-Bus connection, they
are sent to a specific object, not to the application as a whole.
</para>
<para>
@@ -261,7 +261,7 @@
application, and thus can't be passed from one application to another.
</para>
<para>
- To solve this, D-BUS introduces a name for each object. The name
+ To solve this, D-Bus introduces a name for each object. The name
looks like a filesystem path, for example an object could be
named <literal>/org/kde/kspread/sheets/3/cells/4/5</literal>.
Human-readable paths are nice, but you are free to create an
@@ -289,7 +289,7 @@
<sect2 id="messages">
<title>Message Types</title>
<para>
- Messages are not all the same; in particular, D-BUS has
+ Messages are not all the same; in particular, D-Bus has
4 built-in message types:
<itemizedlist>
<listitem>
@@ -331,7 +331,7 @@
<para>
Object paths, interfaces, and messages exist on the level of
- libdbus and the D-BUS protocol; they are used even in the
+ libdbus and the D-Bus protocol; they are used even in the
1-to-1 case with no message bus involved.
</para>
@@ -395,7 +395,7 @@
<title>Addresses</title>
<para>
- Applications using D-BUS are either servers or clients. A server
+ Applications using D-Bus are either servers or clients. A server
listens for incoming connections; a client connects to a server. Once
the connection is established, it is a symmetric flow of messages; the
client-server distinction only matters when setting up the
@@ -403,17 +403,17 @@
</para>
<para>
- A D-BUS <firstterm>address</firstterm> specifies where a server will
+ A D-Bus <firstterm>address</firstterm> specifies where a server will
listen, and where a client will connect. For example, the address
<literal>unix:path=/tmp/abcdef</literal> specifies that the server will
listen on a UNIX domain socket at the path
<literal>/tmp/abcdef</literal> and the client will connect to that
socket. An address can also specify TCP/IP sockets, or any other
- transport defined in future iterations of the D-BUS specification.
+ transport defined in future iterations of the D-Bus specification.
</para>
<para>
- When using D-BUS with a message bus, the bus daemon is a server
+ When using D-Bus with a message bus, the bus daemon is a server
and all other applications are clients of the bus daemon.
libdbus automatically discovers the address of the per-session bus
daemon by reading an environment variable. It discovers the
@@ -422,7 +422,7 @@
</para>
<para>
- If you're using D-BUS without a bus daemon, it's up to you to
+ If you're using D-Bus without a bus daemon, it's up to you to
define which application will be the server and which will be
the client, and specify a mechanism for them to agree on
the server's address.
@@ -450,7 +450,7 @@
The interface is also optional, primarily for historical
reasons; DCOP does not require specifying the interface,
instead simply forbidding duplicate method names
- on the same object instance. D-BUS will thus let you
+ on the same object instance. D-Bus will thus let you
omit the interface, but if your method name is ambiguous
it is undefined which method will be invoked.
</para>
@@ -468,11 +468,11 @@
</para>
<sect2 id="glib-typemappings">
- <title>D-BUS - GLib type mappings</title>
+ <title>D-Bus - GLib type mappings</title>
<para>
- The heart of the GLib bindings for D-BUS is the mapping it
- provides between D-BUS "type signatures" and GLib types
- (<literal>GType</literal>). The D-BUS type system is composed of
+ The heart of the GLib bindings for D-Bus is the mapping it
+ provides between D-Bus "type signatures" and GLib types
+ (<literal>GType</literal>). The D-Bus type system is composed of
a number of "basic" types, along with several "container" types.
</para>
<sect3 id="glib-basic-typemappings">
@@ -484,7 +484,7 @@
<tgroup cols="4">
<thead>
<row>
- <entry>D-BUS basic type</entry>
+ <entry>D-Bus basic type</entry>
<entry>GType</entry>
<entry>Free function</entry>
<entry>Notes</entry>
@@ -556,9 +556,9 @@
<sect3 id="glib-container-typemappings">
<title>Container type mappings</title>
<para>
- The D-BUS type system also has a number of "container"
+ The D-Bus type system also has a number of "container"
types, such as <literal>DBUS_TYPE_ARRAY</literal> and
- <literal>DBUS_TYPE_STRUCT</literal>. The D-BUS type system
+ <literal>DBUS_TYPE_STRUCT</literal>. The D-Bus type system
is fully recursive, so one can for example have an array of
array of strings (i.e. type signature
<literal>aas</literal>).
@@ -574,13 +574,13 @@
"natural".
</para>
<para>
- First, D-BUS type signatures which have an "obvious"
+ First, D-Bus type signatures which have an "obvious"
corresponding built-in GLib type are mapped using that type:
<informaltable>
<tgroup cols="6">
<thead>
<row>
- <entry>D-BUS type signature</entry>
+ <entry>D-Bus type signature</entry>
<entry>Description</entry>
<entry>GType</entry>
<entry>C typedef</entry>
@@ -618,15 +618,15 @@
contained type. Why we need this we will see below.
</para>
<para>
- The approach taken is to create these types in the D-BUS GLib
- bindings; however, there is nothing D-BUS specific about them.
+ The approach taken is to create these types in the D-Bus GLib
+ bindings; however, there is nothing D-Bus specific about them.
In the future, we hope to include such "fundamental" types in GLib
itself.
<informaltable>
<tgroup cols="6">
<thead>
<row>
- <entry>D-BUS type signature</entry>
+ <entry>D-Bus type signature</entry>
<entry>Description</entry>
<entry>GType</entry>
<entry>C typedef</entry>
@@ -696,7 +696,7 @@
</informaltable>
</para>
<para>
- D-BUS also includes a special type DBUS_TYPE_DICT_ENTRY which
+ D-Bus also includes a special type DBUS_TYPE_DICT_ENTRY which
is only valid in arrays. It's intended to be mapped to a "dictionary"
type by bindings. The obvious GLib mapping here is GHashTable. Again,
however, there is no builtin <literal>GType</literal> for a GHashTable.
@@ -710,7 +710,7 @@
<tgroup cols="6">
<thead>
<row>
- <entry>D-BUS type signature</entry>
+ <entry>D-Bus type signature</entry>
<entry>Description</entry>
<entry>GType</entry>
<entry>C typedef</entry>
@@ -735,7 +735,7 @@
<sect3 id="glib-generic-typemappings">
<title>Arbitrarily recursive type mappings</title>
<para>
- Finally, it is possible users will want to write or invoke D-BUS
+ Finally, it is possible users will want to write or invoke D-Bus
methods which have arbitrarily complex type signatures not
directly supported by these bindings. For this case, we have a
<literal>DBusGValue</literal> which acts as a kind of special
@@ -750,7 +750,7 @@
</sect2>
<sect2 id="sample-program-1">
<title>A sample program</title>
- <para>Here is a D-BUS program using the GLib bindings.
+ <para>Here is a D-Bus program using the GLib bindings.
<programlisting>
int
main (int argc, char **argv)
@@ -872,9 +872,9 @@
<itemizedlist>
<listitem>
<para>
- An internal D-BUS error, such as an out-of-memory
+ An internal D-Bus error, such as an out-of-memory
condition, an I/O error, or a network timeout. Errors
- generated by the D-BUS library itself have the domain
+ generated by the D-Bus library itself have the domain
<literal>DBUS_GERROR</literal>, and a corresponding code
such as <literal>DBUS_GERROR_NO_MEMORY</literal>. It will
not be typical for applications to handle these errors
@@ -883,8 +883,8 @@
</listitem>
<listitem>
<para>
- A remote D-BUS exception, thrown by the peer, bus, or
- service. D-BUS remote exceptions have both a textual
+ A remote D-Bus exception, thrown by the peer, bus, or
+ service. D-Bus remote exceptions have both a textual
"name" and a "message". The GLib bindings store this
information in the <literal>GError</literal>, but some
special rules apply.
@@ -1149,7 +1149,7 @@
<sect1 id="glib-server">
<title>GLib API: Implementing Objects</title>
<para>
- At the moment, to expose a GObject via D-BUS, you must
+ At the moment, to expose a GObject via D-Bus, you must
write XML by hand which describes the methods exported
by the object. In the future, this manual step will
be obviated by the upcoming GLib introspection support.
@@ -1178,7 +1178,7 @@
</programlisting>
</para>
<para>
- This XML is in the same format as the D-BUS introspection XML
+ This XML is in the same format as the D-Bus introspection XML
format. Except we must include an "annotation" which give the C
symbols corresponding to the object implementation prefix
(<literal>my_object</literal>). In addition, if particular
@@ -1398,14 +1398,14 @@
<sect1 id="python-client">
<title>Python API: Using Remote Objects</title>
<para>
- The Python bindings provide a simple to use interface for talking over D-BUS.
- Where possible much of the inner-workings of D-BUS are hidden behind what looks
+ The Python bindings provide a simple to use interface for talking over D-Bus.
+ Where possible much of the inner-workings of D-Bus are hidden behind what looks
like normal Python objects.
</para>
<sect2 id="python-typemappings">
- <title>D-BUS - Python type mappings</title>
+ <title>D-Bus - Python type mappings</title>
<para>
- While python itself is a largely untyped language D-BUS provides a simple type system
+ While python itself is a largely untyped language D-Bus provides a simple type system
for talking with other languages which may be strongly typed. Python for the most part
tries automatically map python objects to types on the bus. It is none the less good to
know what the type mappings are so one can better utilize services over the bus.
@@ -1419,7 +1419,7 @@
<tgroup cols="3">
<thead>
<row>
- <entry>D-BUS basic type</entry>
+ <entry>D-Bus basic type</entry>
<entry>Python wrapper</entry>
<entry>Notes</entry>
</row>
@@ -1478,21 +1478,21 @@
<sect3 id="python-container-typemappings">
<title>Container type mappings</title>
<para>
- The D-BUS type system also has a number of "container"
+ The D-Bus type system also has a number of "container"
types, such as <literal>DBUS_TYPE_ARRAY</literal> and
- <literal>DBUS_TYPE_STRUCT</literal>. The D-BUS type system
+ <literal>DBUS_TYPE_STRUCT</literal>. The D-Bus type system
is fully recursive, so one can for example have an array of
array of strings (i.e. type signature
<literal>aas</literal>).
</para>
<para>
- D-BUS container types have native corresponding built-in Python types
+ D-Bus container types have native corresponding built-in Python types
so it is easy to use them.
<informaltable>
<tgroup cols="3">
<thead>
<row>
- <entry>D-BUS type</entry>
+ <entry>D-Bus type</entry>
<entry>Python type</entry>
<entry>Python wrapper</entry>
<entry>Notes</entry>
@@ -1505,7 +1505,7 @@
<entry><literal>dbus.Array</literal></entry>
<entry>Python lists, denoted by square brackets [], are converted into arrays and visa versa.
The one restriction is that when sending a Python list each element of the list must be of the same
- type. This is because D-BUS arrays can contain only one element type. Use Python tuples for mixed types.
+ type. This is because D-Bus arrays can contain only one element type. Use Python tuples for mixed types.
When using the wrapper you may also specify a type or signature of the elements contained in the Array.
This is manditory when passing an empty Array to a method on the bus because Python can not guess at the
@@ -1532,7 +1532,7 @@
<entry><literal>DICTIONARY</literal></entry>
<entry><literal>Python dictionary</literal></entry>
<entry><literal>dbus.Dictionary</literal></entry>
- <entry>D-BUS doesn't have an explicit dictionary type. Instead it uses LISTS of DICT_ENTRIES to
+ <entry>D-Bus doesn't have an explicit dictionary type. Instead it uses LISTS of DICT_ENTRIES to
represent a dictionary. A DICT_ENTRY is simply a two element struct containing a key/value pair.
Python dictionaries are automatically converted to a LIST of DICT_ENTRIES and visa versa.
@@ -1569,7 +1569,7 @@
</sect2>
<sect2 id="python-invoking-methods">
<title>Invoking Methods</title>
- <para>Here is a D-BUS program using the Python bindings to get a listing of all names on the session bus.
+ <para>Here is a D-Bus program using the Python bindings to get a listing of all names on the session bus.
<programlisting>
import dbus
@@ -1597,7 +1597,7 @@
This is all fine and good if all you want to do is call methods on the bus and then exit. In order to
do more complex things such as use a GUI or make asynchronous calls you will need a mainloop. You would use
asynchronous calls because in GUI applications it is very bad to block for any long period of time. This cause
- the GUI to seem to freeze. Since replies to D-BUS messages can take an indeterminate amount of time using async
+ the GUI to seem to freeze. Since replies to D-Bus messages can take an indeterminate amount of time using async
calls allows you to return control to the GUI while you wait for the reply. This is exceedingly easy to do in
Python. Here is an example using the GLib/GTK+ mainloop.
<programlisting>
@@ -1631,8 +1631,8 @@
<para>
You will also notice that I check the version of the dbus bindings before importing dbus.glib. In older versions
glib was the only available mainloop. As of version 0.41.0 we split out the glib dependency to allow for other mainloops
- to be implemented. Notice also the python binding version does not match up with the D-BUS version. Once we reach 1.0
- this should change with Python changes simply tracking the D-BUS changes.
+ to be implemented. Notice also the python binding version does not match up with the D-Bus version. Once we reach 1.0
+ this should change with Python changes simply tracking the D-Bus changes.
While the glib mainloop is the only mainloop currently implemented, integrating other mainloops should
be very easy to do. There are plans for creating a a generic mainloop to be the default for non gui programs.
</para>
@@ -1747,7 +1747,7 @@
<sidebar>
<title>Version Alert</title>
<para>
- The Python D-BUS bindings require version 2.4 or greater of Python when creating D-BUS objects.
+ The Python D-Bus bindings require version 2.4 or greater of Python when creating D-Bus objects.
</para>
</sidebar>
@@ -1815,7 +1815,7 @@
Notice the @ symbol on the line before the hello method. This is a new directive introduced in
Python 2.4. It is called a decorator and it "decorates" methods. All you have to know is that
it provides metadata that can then be used to alter the behavior of the method being decorated.
- In this case we are telling the bindings that the hello method should be exported as a D-BUS method
+ In this case we are telling the bindings that the hello method should be exported as a D-Bus method
over the bus.
</para>
</sidebar>
@@ -1900,7 +1900,7 @@
<sect2 id="python-inheriting-and-overriding">
<title>Inheriting from HelloWorldObject</title>
<para>
- One of the cool things you can do in Python is inherit from another D-BUS object. We use this trick in
+ One of the cool things you can do in Python is inherit from another D-Bus object. We use this trick in
the bindings to provide a default implementation for the org.freedesktop.DBus.Introspectable interface.
Let's inherit from the HelloWorldObject example above and overide the hello method to say goodbye.
<programlisting>
@@ -1934,7 +1934,7 @@
<sect2 id="python-conclusion">
<title>Conclusion</title>
<para>
- As you can see, using D-BUS from Python is an extremely easy proposition. Hopefully
+ As you can see, using D-Bus from Python is an extremely easy proposition. Hopefully
the tutorial has been helpful in getting you started. If you need anymore help please
feel free to post on the <ulink url="http://lists.freedesktop.org/mailman/listinfo/dbus/">mailing list</ulink>.
The Python bindings are still in a state of flux and there may be API changes in the future.
Index: introspect.dtd
===================================================================
RCS file: /cvs/dbus/dbus/doc/introspect.dtd,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- introspect.dtd 18 Aug 2005 04:04:57 -0000 1.3
+++ introspect.dtd 3 Aug 2006 20:34:36 -0000 1.4
@@ -1,8 +1,8 @@
-<!-- DTD for D-BUS Introspection data -->
-<!-- (C) 2005-02-02 David A. Wheeler; released under the D-BUS licenses,
+<!-- DTD for D-Bus Introspection data -->
+<!-- (C) 2005-02-02 David A. Wheeler; released under the D-Bus licenses,
GNU GPL version 2 (or greater) and AFL 1.1 (or greater) -->
-<!-- see D-BUS specification for documentation -->
+<!-- see D-Bus specification for documentation -->
<!ELEMENT node (node|interface)*>
<!ATTLIST node name CDATA #IMPLIED>
- Previous message: dbus COPYING, 1.5, 1.6 ChangeLog, 1.1059, 1.1060 Doxyfile.in, 1.10,
1.11 HACKING, 1.14, 1.15 configure.in, 1.159, 1.160
- Next message: dbus/tools dbus-cleanup-sockets.1, 1.1, 1.2 dbus-cleanup-sockets.c,
1.2, 1.3 dbus-launch.1, 1.5, 1.6 dbus-launch.c, 1.13,
1.14 dbus-monitor.1, 1.5, 1.6 dbus-send.1, 1.6,
1.7 dbus-send.c, 1.20, 1.21 dbus-viewer.c, 1.16, 1.17
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the dbus-commit
mailing list