dbus-send use?
Havoc Pennington
hp at pobox.com
Thu Jun 10 12:15:34 PDT 2010
Hi,
2010/6/10 ttlee1984 <ttlee1984 at gmail.com>:
> By the way, I have to say I am not quite clear why this argument is
> necessary. Sure it represents the connection to the bus, but in our method
> calling case, isn't it enough to have 1) object path and 2) method name
> (including interface)? It is also my question in the Qt API createMethodCall
> I pasted before. I always get confused about these concepts.
>
Without --dest, dbus-daemon does not know which process you want to
send your message to.
http://dbus.freedesktop.org/doc/dbus-faq.html#id265859
http://dbus.freedesktop.org/doc/diagram.png
http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-names
The "well-known bus name" is in contrast to the "unique" bus name. The
unique name is auto-assigned, dynamic, and never recycled, while the
well-known name is predetermined by some specification.
It is often necessary to route messages to the unique bus name rather
than the well-known name in order to avoid some kinds of race
condition. If you want a fixed process ID (even if that PID crashes)
you need to use the unique name, while if you want "whatever running
process has the well-known name right this second" you can use the
well-known name. A common case is that if you're making a series of
interdependent method calls, if you fail to use the unique name some
calls may go to a process, then the process crashes or exits, then
some calls go to another replacement process.
The "service name" refers to a bus name found in a .service file and
used to auto-activate a service. These will be well-known bus names
always. Because not all bus names go with a launchable service, and
not all apps on the bus are services, the spec and so forth usually
say "bus name" for precision. i.e. a purely client app that has no
well-known names, would be on the bus but would not be a service.
Havoc
More information about the dbus
mailing list