| Revision as of 15:32, 19 April 2006 edit84.102.180.252 (talk)No edit summary← Previous edit | Revision as of 23:21, 3 May 2006 edit undoFrap (talk | contribs)Autopatrolled, Extended confirmed users, File movers, Pending changes reviewers, Rollbackers33,222 editsmNo edit summaryNext edit → | ||
| Line 3: | Line 3: | ||
| ==Introduction== | ==Introduction== | ||
| ==Architecture== | ==Architecture== | ||
| It is an |
It is an ] (IPC) system with three architectural layers: | ||
| * A library, ''libdbus'', that allows two applications to connect to each other and exchange messages. | * 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. | * 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. | ||
| Line 10: | Line 9: | ||
| D-BUS is designed for two specific cases: | D-BUS is designed for two specific cases: | ||
| * 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 ] ] 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 ], where the operating system would typically include the ] and any system ] or ]. | * Communication between the desktop session and the ], where the operating system would typically include the ] and any system ] or ]. | ||
| Line 19: | Line 17: | ||
| 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. | ||
| 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 preferred, but developers are free to create an object named /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application. | 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 <tt>/org/kde/kspread/sheets/3/cells/4/5</tt>. Human-readable paths are preferred, but developers are free to create an object named <tt>/com/mycompany/c5yo817y0c1y1c5b</tt> if it makes sense for their application. | ||
| The D-BUS objects' name is ] to ensure different code modules are kept separated. Namespaces are generally prefixed with the | The D-BUS objects' name is ]d to ensure different code modules are kept separated. Namespaces are generally prefixed with the developers domain name components (eg. <tt>/org/kde</tt>). | ||
| developers domain name components (eg /org/kde). | |||
| == External links == | == External links == | ||
| * | * | ||
| * | * | ||
| ] | ] | ||
Revision as of 23:21, 3 May 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 an Inter-process 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 preferred, 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).