- Reliability of message delivery.
- Globally consistent message ordering.
- Providing broadcast notifications of changes.
- If you're using kdbus, trust of the identity of the message sender.
D-Bus is not designed for:
Bulk transport of data:
For that you may want to use a pipe or regular file descriptor.
Turning Linux into a microkernel.
Microkernels are known for having very fast IPC, and do every operation by sending a message to some other component.
It is tempting to build microkernel semantics on top of Linux by having services react to messages and perform the required actions, rather than using system calls.
The overhead involved in using D-Bus is too great for this.
Application frameworks often build on top of this to provide proxy objects, so that you can effectively refer to objects in different processes.
By providing a well known name where a D-Bus object may be found, you can have local services provide an API for performing operations, and local applications instruct these services to perform operations.
A more detailed description of what D-Bus is and its concepts,
can be found here.
The article is about
sd-bus, but the "What is D-Bus again?" and
"Introduction to D-Bus Concepts" sections are relevant to understanding D-Bus.