Starting the kdbus discussions
alp at nuanti.com
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 gould.cx) 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