Legend:
Library
Module
Module type
Parameter
Class
Class type
D-Bus peers
A D-Bus peer represent an application which can be reach though a D-Bus connection. It is the application at the end-point of the connection or, if the end-point is a message bus, any application connected to it.
Note that it is possible to use either a unique connection name or a bus name as peer name.
Both possibility have advantages and drawbacks:
using bus names such as "org.freedesktop.DBus.Hal" avoid the need to resolve the name. When doing the first method call the bus will automatically start the service if available. Also if the service restarts the peer will still be valid.
One drawback is that the owner may change over the time, and method calls may not be made on the same peer.
using a unique name, which can be retreived with bus functions (see OBus_bus), ensures that the peer won't change over time. By the way if the service exits, or another application replaces it and we want to always use the default one, we have to write the code to handle owner change.
So, one good strategy is to use bus names when calls do not involve side-effect on the service such as object creation, and use unique names for object created on our demand. Basically you can stick to this rule:
Always use bus name for a well-known objects, such as "/org/freedesktop/Hal/Manager" on "org.freedesktop.Hal.Manager" and use unique name for objects for which the path is retrieved from a method call.