Despite reading through tons of DBus tutorials, I still struggle to understand the whole concept. In my opinion this was one of the best explanations so far:


The reason to use the DBus is because I want to exchange data between different programs. In my opinion, it would suffice to provide a server or, like named in Figure 2-2, a service. This service provides several methods over an interface which I share with the client.

The client then invokes a method and gets an answer.

So what am I missing? Why is there a need of additional objects?

I guess it's just to stick to the Java conventions of objects respectively classes. Each object represents an instance. Would really like someone to confirm that.

What is the benefit of the first system over the second?


  • can you please elaborate a little more,what do you mean by additional objects?
    – Thushi
    Jun 30, 2014 at 11:33
  • To use a metaphor: If I want to talk to another person (service) I will address them as "Steve" (well-known-name, eg. org.freedesktop.DBus) and I will tell them what to do, eg. "give me the squareroot of 4" (methodcall) and he will answer "2" (reply) What doesnt fit into my metaphor is an object, why perform the additional step to address an object of a service? My conclusion is now, that its a conventional thing, to call multiple instances of "Steve". Am I right?
    – Hoppo
    Jun 30, 2014 at 12:00

1 Answer 1


Not by convention but to facilitate high-level bindings.

Native Objects and Object Paths

Your programming framework probably defines what an "object" is like; usually with a base class. For example: java.lang.Object, GObject, QObject, python's base Object, or whatever. Let's call this a native object.

The low-level D-Bus protocol, ..., does not care about native objects. However, it provides a concept called an object path. The idea of an object path is that higher-level bindings can name native object instances, and allow remote applications to refer to them.


Probably you can just use the API and the message bus daemon built in libdbus in order to avoid the use of objects so you will end with your communication approach of a client that invokes a method and gets an answer. However be aware that libdbus is intended to be a low-level backend for the higher level bindings so much of the libdbus API is only useful for binding implementation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .