System D-BUS and $DISPLAY

[David Zeuthen]

On Wed, 2004-06-30 at 05:10 -0400, Havoc Pennington wrote:
> > There was recently a discussion[1] on the bluez-devel mailing list about
> > how this should be handled with the bluetooth pin-code dialog. The
> > conclusion was that the best way currently is not to use activation at
> > all, but to have the application running all the time in the background.
> 
> Exactly, the basic way the system bus is intended to be used is:
>  - the system broadcasts some minimal information as a signal, 
>    such as "device plugged in" or whatever
>  - user desktop sessions respond to that signal by sending 
>    information back to the system or taking some other action
>  - (note plural sessions, the system has to be designed to handle 
>    multiple sessions responding)
> 

This seems a little bit limited in scope, not sure, some ramblings
ahead; to provide good UI for dealing with system-wide events you need a
bit more than pushing signals that all sessions listen for - sometimes,
for security reasons, you want to be more selective about what session
you send a signal to.

So, I think maybe it would make sense to be able to ask the system bus
what session buses are running as well as characteristics of each
session, e.g. whether they are remote or local and what user is logged
etc. etc. 

Basically, I guess this is useful for maintaining system-wide policy
according to preferences specified by user with the current session. The
thing is, you want to store these preferences in either gconf, Kxconfig
or whatever session-wide preference system is running. 

So, for example, maybe the session-wide bus exports a service
implementing some org.freedesktop.bluetooth interface through either a
GNOME or KDE application running in the session (or maybe it's even
activated). When you determine that you need the pincode you query the
sessions available and pick the one you want - most probably one of the
local sessions - and connect to the service to get the pin.

But, yeah, you can do it both ways, I think it varies what you want to
do, dependent on the exact context of what you want to achieve.

> So for bluetooth the system says "I need a PIN!" and the user sessions
> open a dialog to ask for one. David Zeuthen's HAL talk at GUADEC
> yesterday (which is not at http://2004.guadec.org/wiki/DayTwo but maybe
> will be later) discussed a "device manager" per-session daemon that
> would do this kind of thing.
>

FWIW, I've uploaded the presentation here

 http://freedesktop.org/~david/HAL-GUADEC2004.sxi

but I'm struggling with architectural design issues as sketched above.
Hopefully in a few weeks I'll send a proposal to utopia-list on how I'd
like to do this.

Cheers,
David