KDE adoption of D-Bus

[Havoc Pennington]

On Wed, 2006-02-15 at 16:31 +0100, Thiago Macieira wrote:
> 1) Windows and MacOS X support
> KDE4 (or at least KDE 4 applications) is supposed to run on both of those 
> platforms. Has libdbus been ported to those platforms? Does it work? Are 
> there known problems?

Tor Lillqvist started on Windows:
http://lists.freedesktop.org/archives/dbus/2005-December/003885.html
http://lists.freedesktop.org/archives/dbus/2005-May/002637.html
http://lists.freedesktop.org/archives/dbus/2004-November/001783.html

It probably has a fair bit of work remaining though. In principle all
UNIX dependencies are in dbus-sysdeps.c but in reality I know some have
leaked out, and also that the dbus-sysdeps.h interface could be modified
to be more platform-neutral. e.g. it could export a handle object that
had a "socket or file" flag, rather than just an integer file
descriptor, which might simplify the Windows port. Or it could have
explicitly separate socket and file functions.

I know people have reported compiling on OS X, it should be pretty easy
to compile with maybe a couple fixes; the hard part is probably
launching the daemon, but that's the same as your point #2 ...

> In other words, is it possible to use D-Bus session if the daemon isn't 
> running and DBUS_SESSION_BUS_ADDRESS isn't set?

Right now there is no solution, we have relied on distributions changing
their launch scripts that launch the X server to also launch the dbus
daemon using a command called dbus-launch.

A proposal for how to implement auto-launch:

 - modify dbus-launch, or create dbus-launch-x11 - in other 
   words, there's a separate executable that does the autolaunch,
   we don't do this inside the library
 - what this executable does:
   - grab the X server
   - try to read the session's bus daemon off a root window 
     property on screen 0 (note per-display not per-screen,
     so always screen 0)
   - if not present, launch the daemon, read the bus address,
     and set the property
   - ungrab the server
   - provide the session bus address to the calling process
 - when we use dbus-launch to launch the daemon from the 
   session init scripts, dbus-launch should set the 
   root window property as well
 - libdbus should use the algorithm:
   - if DBUS_SESSION_BUS_ADDRESS is present, use it (much faster)
   - else spawn dbus-launch to read the bus address from X11
     and possibly start the daemon if needed
 - dbus-launch should never *replace* the root window property;
   i.e. there's only one daemon per session ever. this is important
   for two reasons:
   - the daemon is supposed to be the lifecycle "grounding point" 
     for the session and exiting it is supposed to indicate that 
     the session is over; its lifetime should match the X server's
   - if DBUS_SESSION_BUS_ADDRESS is set, we never look at the 
     X property, and the env variable can't be changed dynamically.
     So allowing daemon restart would be unreliable.
 - when dbus-launch does an autostart, it sets up the daemon to 
   exit along with the X server, just as it does normally in the 
   session init scripts

This would solve the problem of auto-launch and also solve the problem
of providing the bus address to remote X clients. Though really to make
remote clients work smoothly we need to go one more step and forward the
bus traffic over ssh, at least this way it will work in a no-firewalls
situation (after you turn on tcp for the session bus anyway, it's not on
by default I'm pretty sure).

This problem would need to be solved separately for Windows I would
think, at least for apps that are native to Windows instead of using a
Windows X server; a dbus-launch-win32 might use COM or some other
convenient Windows API to get a singleton object for the user's login
session. In libdbus a simple #ifdef could choose the right dbus-launch
for the platform.

If the above sounds reasonable to you and you have time to hack on it a
bit, would be very welcome.

Havoc