Compatibility between D-Bus and kdbus

[Simon McVittie]

On 25/11/14 23:46, David Herrmann wrote:
> In particular, if gdbus runs AddMatch(), it assumes the match takes
> effect immediately. If it sends a method call to another service after
> installing the match, and this triggers a signal, gdbus assumes the
> AddMatch() call to have succeeded (without waiting for the reply).

Argument in favour of this being sane: if AddMatch() failed, what would
it do about it? The only error that can happen without programmer error
is running out of match rule slots, which can't be recovered from in
traditional D-Bus (but now that
https://code.google.com/p/d-bus/issues/detail?id=10 has been fixed,
kdbus *can* recover).

> I strongly recommend to either drop support for org.freedesktop.DBus
> on any kdbus-aware DBus APIs, or fake it in the library. sd-bus
> doesn't support it, and IIRC Ryan didn't want to fake it in gdbus
> either.

For sd-bus, a new and non-API-stable library, that's reasonable.

For existing libraries, this sounds like an argument in favour of having
a separate DBUS_BUS_SESSION_KDBUS (or whatever you want to call it, but
basically it means "allowed to be kdbus"), to be able to opt-in to
potentially breaking changes: lack of ACLs (definitely a breaking change
on the system bus but arguably not a breaking change on the session
bus), and lack of support for direct o.fd.DBus calls (a breaking change
on both buses).

There are several o.fd.DBus calls for which libdbus doesn't have
high-level API at all, so libdbus users have no option but to use direct
calls. GDBus might be more complete in that respect?

    S