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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
