Specifications

CHAPTER 4. DESIGN AND ARCHITECTURE 26
the project lead. This emphasizes the will of implementing an independent IPC framework,
that does not displease any Gnome or KDE developer, as Freedesktop.org is working on projects
supporting the collaboration and interoperability of desktop environments.
Beside the small amount of dependencies, D-BUS distinguishes itself by offering bindings
for many high-level programming languages. This fact satisfies the fifth functional requirement
(Chapter 3, §3.2), which states the independence regarding the programming language used
by any application utilizing the Input Abstraction Layer’s output interface.
D-BUS offers two different types of message buses: the system bus and the session bus.
The system bus is used by system daemons and D-BUS itself, whereas the session bus is used
for user space applications. While there is only one system bus, it is possible to create an
arbitrary number of session buses. By default, the configuration for the system bus is secured
to prevent user space applications from receiving or sending messages to the interfaces of
the bus. While the system bus is started with the start-up of D-BUS (e.g. system boot),
session buses are started when needed. D-BUS provides several message types to realize the
interprocess communication between applications using one of the buses: method calls, method
returns, signals and errors. Messages can have arbitrary arguments. The data types for these
arguments are defined by the D-BUS protocol and cover basic as well as complex data types.
The interprocess communication is transparent for both the Input Abstraction Layer and
the application using its output interface. Figure 4.4 shows the sequence of the data flow. First,
modules report input events by calling a function provided by the daemon. The abstraction
is realized at this point: the module’s input is concrete, its output is abstract. The modules
use a common function provided by the daemon to report events to the output interface. This
function invokes an IPC function for sending the abstract input event. User space applications
receiving events from the abstract output interface are using a corresponding receive function
offered by the utilized IPC. It is also possible that applications which do not directly read
from the Input Abstraction Layer’s output interface make profit out of the Input Abstraction
Layer. This case requires a broker process (shown as “Process”), which receives events from
the daemon and relays them to an input interface the user space application is using.
Input Abstraction Layer
Output Interface
IAL Module
Event Loop
IAL Module
Application
Application
Application
Clients
IPC
Process
Figure 4.4: Abstract Output Interface