| Revision as of 16:25, 25 December 2005 editNixdorf (talk | contribs)Administrators7,370 edits →How D-BUS Works: copyedit← Previous edit | Revision as of 21:26, 5 January 2006 edit undoBluemoose (talk | contribs)29,151 edits AWB Assisted clean up and fix c++ linksNext edit → | ||
| Line 2: | Line 2: | ||
| ==Introduction== | ==Introduction== | ||
| ==Architecture== | ==Architecture== | ||
| It is a interprocess communication (]) system with three architectural layers: | It is a interprocess communication (]) system with three architectural layers: | ||
| Line 16: | Line 15: | ||
| == How D-BUS Works == | == How D-BUS Works == | ||
| Each application using D-BUS contains objects, which generally (but need not) map to GObject, QObject, ] objects, or ] 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 ], as it appears to the user as if an object is ] across the IPC connection, no matter if there is an object on the other side or not. | Each application using D-BUS contains objects, which generally (but need not) map to GObject, QObject, ] objects, or ] 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 ], as it appears to the user as if an object is ] 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 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. | ||
| Line 29: | Line 28: | ||
| * | * | ||
| ⚫ | ] | ||
| ] | ] | ||
| ] | ] | ||
| ⚫ | ] | ||
Revision as of 21:26, 5 January 2006
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).