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.
Pervasives.compare. It allows this module to be used as argument to the functors
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.
make connection name make a named peer
Ping a peer, and return the peer which really respond to the ping.
For example, the fastest way to get the the peer owning a bus name, and start it if not running is:
ping (OBus_peer.make bus "well.known.name")
wait_for_exit peer wait until
peer exit. If
peer is not running then it returns immediatly. Raises
Invalid_argument if the peer has no name.
type peer = t
module type Private = sig ... end
Minimal interface of private peers
module Private : sig ... end
Minimal implementation of private peers