Starting the kdbus discussions

[Simon McVittie]

On 02/01/14 01:18, Lennart Poettering wrote:
> 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.

I would like these features' documentation to note their
non-portability. It would be great if it was easy to distinguish between
"baseline D-Bus" (available everywhere that either libdbus or GDBus has
been ported), the various features available on every sensible Unix (for
some definition of sensible) but not on Windows or more limited Unixes,
and the features that are highly OS-specific (usually to Linux, but I
think there's one Solaris-specific method).

Features available on "every sensible Unix" currently include the system
bus, fd-passing, and use of credentials-passing to avoid needing
DBUS_COOKIE_SHA1 (for a somewhat narrower definition of sensible that
includes Linux and most BSDs).

    S