Starting the kdbus discussions

Alp Toker alp at
Sun Dec 29 19:15:24 PST 2013

On 29/12/2013 20:29, Lennart Poettering wrote:
> On Sun, 29.12.13 13:52, Ted Gould (ted at wrote:
>> On Fri, 2013-12-27 at 01:04 +0100, Lennart Poettering wrote:
>>> This makes us comfortable to start discussion on the dbus ML regarding
>>> the details and what this means for the dbus spec. I have put together a
>>> document now that explains what we are doing and how to port a dbus1
>>> library over to a kdbus backend. Much of this hopefully should end up in
>>> the dbus spec one day.
>> Glad that you're ready to start talking about this.  I guess the
>> question I really want to ask is perhaps the elephant in the room.  With
>> a different serialization format, a different name registration scheme,
>> different connection parameters, different service description files...
>> heck, some of the fields seem arbitrarily inverted.   This doesn't seem
>> like DBus at all, but something entirely different, more "DBus inspired"
>> rather than something related to DBus itself.
> Nope. We provide quite complete compatibility, there are only very few
> exceptions visible to app programmers.

Speaking now as an outsider myself, I think Ted was making an 
observation about the wire protocol rather than developer APIs.

> One is the different policy language
> use for the system bus, but even for that we provide full compatbility
> if people connect via the good old AF_UNIX protocol.

Perhaps a word diff against the standard D-Bus protocol definition will 
help allay concerns like Ted's, and make sure the various D-Bus 
libraries adopt any tweaks to remain compatible.

If I can connect with AF_UNIX and communicate the same way on the wire, 
then it's still D-Bus and I really don't see the problem here.


the browser experts

More information about the dbus mailing list