D-BUS (Desktop Bus) is a simple inter-process communication (IPC) open-source system for software applications to communicate with one another. It replaced DCOP in KDE4 and has also been adopted by Gnome, XFCE and other desktops. It’s, in fact, the main interoperability mechanism in the “Linux desktop” world thanks to the freedesktop.org standards.
The architecture of D-Bus is pretty simple: there is a dbus-daemon server process which runs locally and acts as a “messaging broker” and applications exchange messages through the dbus-daemon.
But of course you already new that because you are supersmart developers and/or users.
D-Bus on Windows
What you may not know is how much damage is D-Bus making to open source software on Windows.
A few years ago I tried to introduce kdelibs for a large cross-platform project but I got it rejected, despite some obvious advantages, mainly due to D-Bus.
Performance and reliability back then was horrible. It works much better these days but it still scares Windows users. In fact, you may also replace “it scares Windows users” with “it scares IT departments in the enterprise world*”.
The reason?
A dozen processes randomly started, IPC with no security at all, makes difficult to upgrade/kill/know when to update applications, and many more. I’m not making this out, this has already happened to me.
* yes, I know our friends from Kolab are doing well, but how many KDE applications on desktop have you seen out of that “isolation bubble”
D-Bus on mobile
One other problem is D-Bus is not available on all platforms (Android, Symbian, iOS, etc), which makes porting KDE applications to those platforms difficult.
Sure, Android uses D-Bus internally, but that’s an implementation detail and we don’t have access to it). That means we still need a solution for platforms where you cannot run or access dbus-daemon.
Do we need a daemon?
A few months ago I was wondering: do we really need this dbus-daemon process at all?
What we have now looks like this:
As you can see, D-Bus is a local IPC mechanism, i. e. it does not allow applications to communicate over the network (although technically, it would not be difficult to implement). And every operating system these days has its own IPC mechanism. Why create a new one with a new daemon? Can’t we use an existing one?
I quickly got my first answer: D-Bus was created to expose a common API (and message and data format, i. e. a common “wire protocol”) to applications, so that it’s easy to exchange information.
As for the second answer, reusing an existing one, it’s obvious we cannot: KDE applications run on a variety of operating systems, every one of them has a different “native” IPC mechanism. Unices (Linux, BSD, etc) may be quite similar, but Windows, Symbian, etc are definitely very different.
No, we don’t!
So I though let’s use some technospeak buzzword and make HR people happy! The façade pattern!
Let’s implement a libdbusfat which offers the libdbus API on one side but talks to a native IPC service on the other side. That way we could get rid of the dbus-daemon process and use the platform IPC facilities. For each platform, a different “native IPC side” would be implemented: on Windows it could be COM, on Android something else, etc
Pros
The advantage of libdbusfat would be applications would not need any change and they would still be able to use DBus, which at the moment is important for cross-desktop interoperability.
On Unix platforms, applications would link to libdbus and talk to dbus-daemon.
On Windows, Android, etc, applications would link to libdbusfat and talk to the native IPC system.
By the magic of this façade pattern, we could compile, for instance, QtDBUS so that it works exactly like it does currently but it does not require dbus-daemon on Windows. Or Symbian. Or Android.
QtMobility?
QtMobility implements a Publish/Subscribe API with a D-Bus backend but it serves a completely different purpose: it’s not available glib/gtk/EFL/etc and it’s implemented in terms of QtDBUS (which in turn uses dbus-daemon for D-Bus services on every platform).
It’s, in fact, a perfect candidate to become a user of libdbusfat.
Cons
A lot of work.
You need to cut dbus-daemon in half, establish a clear API which can be implemented in terms of each platform’s IPC, data conversion, performance, etc. Very interesting work if you’ve got the time to do it, I must say. Perfect for a Google Summer of Code, if you already know D-Bus and IPC on a couple of different-enough two platforms (Linux and Windows, or Linux and Android, or Linux and iOS, etc).
Summary
TL;DR: The idea is to be able to compile applications that require DBus without needing to change the application. This may or may not be true on Android depending on the API, but it is true for Windows.
Are you brave enough to develop libdbusfat it in a Qt or KDE GSoC?
You might want to take another look at Mobility P&S. It doesn’t rely on dbus, as that means it wouldn’t have been possible to make it work on Symbian. It has different backends. The code you want to look at is in src/serviceframework/ipc/ in qtsystems in Qt 5.
That doesn’t mean it would necessarily be a great fit for anything like this, I’m just pointing it out.
Robin,
It’s probably not clear enough from my post, but I said the D-Bus backend is *one* of the backends for Mobility P&S. Of course there are other backends for Symbian, etc.
Maybe if Mobility P&S had been available 7 years ago that would have been what freedesktop.org would have taken as the standard for cross-desktop IPC. But it was not and D-Bus was adopted. And now we need to solve the problem of D-Bus on many platforms. That’s the problem libdbusfat would solve.
The whole point of libdbusfat is to be able to build and use applications that require D-Bus without dbus-daemon on platforms where it is not available.
This is a great idea, but you might get further by demonstrating the value of your idea by solving a simpler problem, which is to create a library with a DBUS client API which works on Windows using the native IPC mechanisms (I suggest named pipes and mailslots). That way KDE applications can be compiled on windows and not require the DBUS daemon.
Isn’t that exactly what I’m proposing?
What is the point in supporting windows?
I am not sure this is feasible. The part of D-Bus usage that is communication between applications is most likely implementable that way, but what about the services provided by the D-Bus daemon?
E.g. atomically acquiring a D-Bus name, activating a receipient on first call, etc.
Why not just port dbus-daemon to the mobile platforms? (In the case of Android, there are even 2 possible solutions: either hack into the native instance(s) or just spawn your own.)
So your proposal is instead of getting rid of the problem on the platforms where it does not currently exist, we create the problem on those platforms too. Doesn’t look good to me.
That’s because you’re adopting your users’ misguided and naïve view that dbus-daemon is a “problem” rather than a desirable feature.
Could you please explain how having one more daemon running when you can get by without having that daemon running is misguided and naïve view?
The daemon might not be as unnecessary as you think. See e.g. the features Kevin Krammer pointed out. And even for pure communication, translating D-Bus messages to the native IPC API is going to be less efficient than just using D-Bus.
Now it might be workable anyway, but it doesn’t exist right now, so porting dbus-daemon is the much simpler solution to the problem. (And it’s definitely a better solution than hacking out all the D-Bus code from the Android ports of applications and libraries as is done now.)