[systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans

[Simon McVittie]

On 25/03/13 13:28, Greg KH wrote:
> The "ideas" only, the wire protocol is quite different, and in reality,
> unknown as it isn't implemented yet, so all of your questions are a bit
> premature, sorry.

Sure. When you have (proposed) answers to these questions, please talk
to the D-Bus maintainers before advertising anything as ready for use as
a replacement for D-Bus; or if you have questions of your own, the dbus
mailing list is a good place to ask.

What I would particularly like to avoid is something that calls itself
D-Bus but does not have compatible semantics. Not everything that can be
said about D-Bus is immediately obvious, and I'd like to avoid having to
rediscover what its users rely on. My questions about kdbus should
illustrate some of the areas that should be considered.

> And odds are, there will not need to be a flag-day [for dbus-java etc.]
> either, if the
> library ends up being plug-in compatible for userspace applications.
> Which is the goal.

Please note that there are two broad classes of D-Bus libraries:

* Wrappers around libdbus (such as QtDBus, dbus-glib, Upstart's
  libnih, and dbus-python). These use libdbus' public API, and can use
  alternative transports (even those not based on sockets) as soon
  as libdbus can, as long as those alternative transports provide
  compatible semantics.

* Complete implementations of the D-Bus protocol (such as
  libdbus itself, GDBus, dbus-java, and now libsystemd-bus). These
  implement the whole protocol and do not share code with each other;
  replacing libdbus does not help the rest of these.

libdbus' shortcomings as a "bindable" library, and its inconvenient
licensing (GPL|AFL dual-license, unable to be changed due to a copyright
holder that has gone out of business), have led to an increasing number
of reimplementations, particularly for high-level languages and in
environments where the LGPL or a BSD-style license is conventional.

    S