Howto determine the dbus session address??
stef at bononline.nl
Wed Aug 18 07:07:51 PDT 2010
On 08/18/2010 03:18 PM, Havoc Pennington wrote:
> Rui is right that dbus was designed to handle system events as:
> - notification on system bus (or via other system mechanism)
> - something in user's session listening on system bus detects this
> and does whatever (possibly using the session bus)
> And this is how things generally work in a typical Linux install; the
> system is never broadcasting to all session buses, as far as I know.
> Instead stuff in the user sessions monitors the system.
> It doesn't mean your approach isn't a possible design, just that it
> isn't the actual design. As a result, the infrastructure is not in
> place for that. You could imagine patching the session bus code to
> connect to the system bus and register, so you could then get a list
> of session buses, for example. But this has not been done so would
> have to be done.
> if you don't want to go hacking on dbus or other system software, the
> path of least resistance for sure would be to work with the way things
> are currently designed.
> In short there is not a way right now to get session bus addresses
> from outside the session. (Other than gross hacks of some kind.)
Thanks a lot for your clear explanation. It has become clear to me that
it's not possible
for me a simple way.
As a result I will make my scripts use wall.
Also I have to conclude that communication of my construction and the
is not possible through design. It has also become clear that the
sending a user a message via
the session dbus (org/freedesktop/Notifications) is not that good, when
dealing with a softwareconstruction like mine.
Again my construction is about offering the user easy access to various
resources using a FUSE
module and the automounter (and a lot more). It does not depend on the
environment (textbased or graphical), works on filesystem level, and is
- as you look at it closely - not system related nor session.
It's started once for every user logged in. If somehow the user logs in
more than once, the services my construction offers do not change.
When looking at how the notification of a new device now works,
everything is handled
in the session. The device manager is running in a session, and gets
it's input from HAL.
Now that's the big difference, my construction is not part of the
session, but more related to
whether the user is logged in or not.
It should be better when the org.freedekstop.Notification service has a
system part. The session parts (do you name that this way) are connected
to the system bus, for general messages.
I hope I can convince the creators of this service of my suggestions...
More information about the dbus