DBus on "other" platforms

[Simon McVittie]

On 12/05/16 10:11, René J. V. Bertin wrote:
> There have been a number of remarks on KDE mailing list recently about how "DBus 
> is a fish out of the water" or "not a common service" on OS X (and MSWin). The 
> latter isn't untrue, but the former?

As far as I'm aware, Apple don't install dbus by default, provide it in
a readily available software repository or anything like that, whereas
most GNU and *BSD distributions either install it by default or make it
very easy to obtain and depend on. So D-Bus is clearly less "common" on
OS X than on GNU and *BSD, and that's the OS vendor's choice, not ours.

(I'm deliberately saying "GNU" rather than "Linux" here, because D-Bus
is equally "uncommon" on Android Linux, even though the kernel clearly
has everything needed to run it.)

If you have a straightforward way to install the dbus binaries and start
the well-known session bus, then D-Bus might still be useful for
communication between cooperating applications (such as the KDE suite)
on platforms where it is "uncommon".

The well-known system bus is not necessarily very useful on platforms
where D-Bus is "uncommon", because if it isn't normally installed, then
the API that the OS developer offers to applications clearly isn't going
to be provided that way. In contrast, on GNU/Linux and to a lesser
extent *BSD, system bus services like systemd, NetworkManager, ConnMan,
BlueZ, accountsservice are among the known and recommended ways for
applications to do certain things.

> To what extent do DBus developers consider DBus to be a (potential) cross-
> platform Desktop Bus solution?

https://lists.freedesktop.org/archives/dbus/2013-October/015825.html
summarizes our approach to how cross-platform or otherwise we are.

Our primary target for D-Bus is GNU/Linux, where it is widely considered
to be core system infrastructure; it is entirely possible to set up a
fully working system without it, but important services like systemd and
NetworkManager strongly recommend having D-Bus, and popular higher-level
suites like GNOME and KDE often won't work without it.

If users of other Unix OS distributions (*BSD, etc.) want D-Bus to be a
first-class citizen on their platforms, they are invited to contribute
via bug reports and patches, and perhaps eventually become D-Bus
maintainers themselves. We try to keep the specification (D-Bus) and the
reference implementation (dbus) portable, but we can't know whether it
works on platforms we don't run unless someone tries it and reports back.

Similarly, if the developers of Unix distributions want to integrate
D-Bus into their OSs as a piece of important infrastructure, they're
very welcome to do so; but if it goes wrong, we would prefer that they
talk to us about it, rather than working around it downstream.

> I understand that many if not most of the
> adaptations to make it run on MSWin were incorporated

They were, and one of their authors is an active D-Bus maintainer. That
does not imply that D-Bus on Windows has the same level of quality,
security or OS integration that it does on GNU or *BSD.

In particular, D-Bus was really designed with AF_UNIX sockets in mind.
Those don't exist on Windows, so we have to fall back to localhost TCP
sockets, which are slower and less featureful (for instance we can't do
EXTERNAL authentication).

> but I have to notice that
> there are still some patches being applied by the MacPorts port on OS X (= the 
> version I'm running): 
> https://trac.macports.org/browser/trunk/dports/devel/dbus/files

Please encourage the maintainers of that port, and anyone else
maintaining D-Bus "downstream", to talk to us about getting their
changes integrated, or at least reviewed.

Downstreams' patches are often (although not always) reasonably easy to
find; the part that isn't easy to find for a non-expert, but is vitally
important for reviews, is an explanation of what problem the patch is
solving, so that a reviewer can make an informed assessment of whether a
different solution would be better. Sorry, we don't have time to go
looking for these in all the downstream distributions.

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>