<?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>
+ It helps to keep these concepts separate in your mind:
+ <orderedlist>
+ <listitem>
+ <para>
+ Object/component system
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GUI control/widget embedding interfaces
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Interprocess communication system or wire protocol
+ </para>
+ </listitem>
+ </orderedlist>
+ </para>
+ <para>
D-Bus is not a component system. "Component system" was originally
defined by COM, and was essentially a workaround for the limitations
of the C++ object system (adding introspection, runtime location of
in modern languages all objects are effectively "components."
</para>
<para>
- A third, orthogonal feature is interprocess communication or IPC.
+ So components are fancy objects, and some objects are GUI controls.
+ </para>
+ <para>
+ A third, unrelated feature is interprocess communication or IPC.
D-Bus is an IPC system. Given an object (or "component" if you must),
you can expose the functionality of that object over an IPC system.
Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus.
then you can have an out-of-process or dynamically-loaded GUI control.
</para>
<para>
- Summarizing, there are three orthogonal things:
- <orderedlist>
- <listitem>
- <para>
- Object/component system
- </para>
- </listitem>
- <listitem>
- <para>
- Control embedding interfaces
- </para>
- </listitem>
- <listitem>
- <para>
- Interprocess communication system or wire protocol
- </para>
- </listitem>
- </orderedlist>
- </para>
- <para>
Another related concept is the <firstterm>plugin</firstterm> or
<firstterm>extension</firstterm>. Generic plugin systems such as the
<ulink url="http://eclipse.org">Eclipse</ulink> system are not so different
</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
projects / platform / upstream / dbus.git / blobdiff