Starting the kdbus discussions

[Lennart Poettering]

On Wed, 01.01.14 22:38, Kevin Krammer (krammer at kde.org) wrote:

> Hi Lennart,
> 
> On Friday, 2013-12-27, 01:04:19, Lennart Poettering wrote:
> > Heya,
> > 
> > We today reached a milestone in kdbus development, that we have all the
> > bits in pieces in place to boot a full system with kdbus as system bus
> > and no dbus-daemon in the mix for it. The only missing bit is policy
> > enforcement, everything else is there.
> 
> When you write "kdbus as system bus" does that imply it is also being used for 
> session busses (since those are usually "easier") or is kdbus only used for 
> system bus and session busses are still backed by dbus-daemon?

Our primary focus for now is the system bus, and dbus-daemon can
continue to be used for the session bus, even on a system that uses
kdbus for the system bus.

Adopting kdbus for the session is politically more complex. In the
systemd model there is after all no dbus-daemon anymore, there's just
the systemd system instance that sets up the system bus, and then the
systemd user instance that sets up the user bus. Which means that
desktops which want to take benefit of kdbus would also have to adopt
systemd as a session manager. That of course is politically difficult
for people. Colin Walters and some folks at Intel have started making
this work for GNOME and KDE systems as well as other desktops, but
asking the desktops to just drop their own session management and do it
with systemd only is going to be diffcult, especially given that there
are still some bits missing (for example a native .desktop file parser
in systemd, so that we can run .desktop files as systemd user services
-- but maybe this is not an issue anymore with Ryan's bus hookup for
desktop files). Of course, I believe that there's a lot for desktops to
earn if they use systemd as session manager (especially as we start
containerizing apps and need cgroups hookup and things), but there's
also a lot to loose, because more systemd in the desktop makes
traditionalists and ubuntu folks cry.

> Will this affect users of D-Bus on non-Linux system (BSD, OSX, Windows) in 
> some way?

I don't see how really.

I mean, there are a few things that kdbus can do that dbus-daemon
can't. For example race-freely supply user credentials, or a race-free
way to disconnect from the bus for exit-or-idle without losing messages,
or memfds are sending huge blobs around for free. If people make use of
this, then things will be great on kdbus backends, but on classic
backends things might break, get slow, or racy. But this is really up to
the app developer: if he makes use of these features he loses
portability. It's like the existing support for passing unix fds via
dbus: if you make use of that, of course you are not portable anymore,
and the recipe for portability is certainly tha you shouldn't use unixfd
passing if you care about windows.

Lennart

-- 
Lennart Poettering, Red Hat