Compatibility between D-Bus and kdbus

[Thiago Macieira]

On Wednesday 26 November 2014 13:02:52 Simon McVittie wrote:
> 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).

A new environment variable? I"m not sure how that follows from the discussion. 
Can you elaborate?

> 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?

Same with QtDBus. And even if the lib does provide all high-level calls, 
there's nothing stopping user code from making calls by itself anyway. Hence, 
a compatibility layer is necessary, either by intercepting the calls and 
translating, or by having a service on the bus.

Now, it has just occurred to me that we'll need at the very least to intercept 
signal connections to NameOwnerChanged and possibly NameAcquired and 
NameReleased. But if we can do it without intercepting every outgoing call, it 
would be greatly appreciated.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358