Status of kdbus, and other dbus-daemons

[Simon McVittie]

On 15/05/13 08:14, Tim Sander wrote:
>> That will begin to change when kdbus comes along.
> Do you have more info on this? As these KDBus guys have a rather strange 
> communication behaviour (e.g. not using this list?)

I don't know any more than the list does. It seems the KDBus people are
keen to keep quiet and avoid bikeshedding until they have a
fully-working prototype, which seems reasonable (as long as feedback is
taken into account once it works).

I think the plan for KDBus (unlike earlier kernel-assisted-D-Bus
prototypes) was for the kernel part to take over all of dbus-daemon's
responsibilities, at which point "that's a dbus-daemon feature" would
become "that's a dbus-daemon or kdbus feature, depending on platform".

Known dbus-daemon implementations:

* libdbus' reference dbus-daemon (from fd.o dbus/dbus.git)

  - the one everyone uses now, in practice

  - Collabora's efforts towards kernel-assisted D-Bus (AF_BUS and
    AF_DBUS) also used libdbus' dbus-daemon (suitably modified)
    rather than a rewrite; the kernel part took over parts of
    its functionality, but the dbus-daemon still did non-fast-path
    bits like name ownership

* GLib's gdbus-daemon (from GNOME glib.git)

  - mainly intended for regression tests; I don't think it has
    the full dbus-daemon feature-set, particularly not the system bus
    parts, but it might be enough to implement a session bus

* ndesk-dbus (dbus-sharp)'s "managed dbus-daemon"

  - I'm sure it used to exist, but I can't even find source code for
    this