This is an old revision of this page, as edited by Bluemoose (talk | contribs) at 21:26, 5 January 2006 (AWB Assisted clean up and fix c++ links). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Revision as of 21:26, 5 January 2006 by Bluemoose (talk | contribs) (AWB Assisted clean up and fix c++ links)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)D-BUS is the name of a computer software system that provides a simple way for different applications to communicate with each other. It is developed as part of the freedesktop.org project.
Introduction
Architecture
It is a interprocess communication (IPC) system with three architectural layers:
- A library, libdbus, that allows two applications to connect to each other and exchange messages.
- A message bus daemon executable, built on libdbus, that multiple applications can connect to. The daemon can route messages from one application to zero or more other applications.
- Wrapper libraries based on particular application frameworks.
D-BUS is designed for two specific cases:
- Communication between desktop applications in the same desktop session; to allow integration of the desktop session as a whole, and address issues of process lifecycle.
- Communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes.
How D-BUS Works
Each application using D-BUS contains objects, which generally (but need not) map to GObject, QObject, C++ objects, or Python objects. An object is an instance rather 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. In this way, D-BUS resembles software componentry, as it appears to the user as if an object is serialized across the IPC connection, no matter if there is an object on the other side or not.
To allow messages to specify their destination object, there has to be a way to refer to an object. In many programming languages, this is normally called a pointer or reference. However, these references are implemented as memory addresses relative to the address space of the application, and thus can't be passed from one application to another.
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 /org/kde/kspread/sheets/3/cells/4/5. Human-readable paths are prefered, but developers are free to create an object named /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application.
The D-BUS objects' name is namespaced to ensure different code modules are kept separated. Namespaces are generally prefixed with the developers domain name components (eg /org/kde).