Howto determine the dbus session address??

[Stef Bon]

  On 08/18/2010 03:18 PM, Havoc Pennington wrote:
> Hi,
>
> 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.)
>
> Havoc
>
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 
desktop
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...

Thanks again,

Stef Bon