| Revision as of 06:03, 23 December 2005 editJsmethers (talk | contribs)1,435 edits cat← Previous edit | Revision as of 16:23, 25 December 2005 edit undoNixdorf (talk | contribs)Administrators7,372 edits →Architecture: links addedNext edit → | ||
| Line 12: | Line 12: | ||
| D-BUS is designed for two specific cases: | 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 ] ] 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. | * Communication between the desktop session and the ], where the operating system would typically include the ] and any system ] or ]. | ||
| == How D-BUS Works == | == How D-BUS Works == | ||
Revision as of 16:23, 25 December 2005
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.
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).