Is there a simpler, less-engineered way? Probably, in the truism sense that all software sucks. But then, anyone could have coded this better way and made it work, and they didn't. So the current work has the advantage that somebody did it and it exists. I'll take that.
Knowing the problems solved here I actually think the current stuff is pretty good. Not flawless -it's software - but good. It does pretty much work. Go use 15 year old Linux if you want to replace nostalgic memories with a good dose of how much it sucked :-p
Now, early DBus was a bit lacking in that respect as well, but with GDBus (GLib's DBus implementation) it's become as straightforward as IPC can be, even in plain C; I've seen quite a few people new to the technology that were able to get up to speed with it quickly.
It'll be interesting to see how people are taking DBus and pushing the boundaries of what it can be used for, such as kdbus.
Thank you hp!
dbus is not mostly about IPC.
Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process.
Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability.
Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces.
The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon.
Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.
Examples of the configuration which controls this kind of thing:
https://github.com/mungerd/vncbox/blob/master/data/dbus-conf... http://git.kernel.org/cgit/network/connman/connman.git/tree/...
The implementation got better (actually, systemd partially got rid of many -Kit components which never truly worked, which IMHO, doing us a favor), but the design is still wonky, still poorly documented, very difficult to debug as a result and understand as a whole.
The fact that these tools rely on self-describing protocols with one single implementation without documentation also results in very tight coupling.
It's also shifting the idea of having a cli interface to perform a task to a dbus interface. Often without any documentation of the dbus interface itself to begin with (or with a crappy cli wrapper).
It's not just Desktop Linux; I've noticed the overengineering trend in basically... all software. There's many contributing factors, probably one of the biggest being the second-system effect ("there were some problems with the old way of doing it so let's find a new way that fixes them - and all the problems that could possibly occur in the future, whether or not they may actually become problems"). I think YAGNI needs to be applied far more often than it currently is.
The solution to complexity should not involve adding more complexity.
While DBus featured a huge amount of bombast from the day one while being really slow on useful things. I think they did not even have a proper console client a few years into development and some shipping.
"due to data validation and more "layers""
You can't really have data validation and proper layers without a spec. You just can't, it would be an annoyance instead of useful feature.
Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation.
This is how open source works. People do what they care about. When speed came to the top of the list people did it.
Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.
Well, DBus was politically pushed onto KDE back in the day, when there was a strong interest in making a success out of cooperation efforts in the Linux desktop space. IIRC, KDE was basically strong-armed out of DCOP.
Once it was established as "the official IPC on the two dominant Linux desktops", it would have been difficult to ignore it regardless of its actual quality.
There was no mechanism to strongarm anybody into anything. KDE and GNOME devs told many ideas and many people to take a hike over the years. dbus was simply a matter of figuring out what those developers wanted and focusing on solving the actual problem, rather than hypothetical or philosophical problems.
When dbus was adopted, remember, people had already been down many roads; ad hoc IPC mechanisms, ad hoc communication through files and timestamps, hacks over X11 protocol, DCOP, multiple implementations of CORBA, SOAP, ICE (the old X-associated one), etc. People had wrestled with this problem space a lot and they had some pretty developed ideas about how to do things ideally. dbus was about coalescing those ideas into running code, and that was successful and stuck for a decade-plus now.
People sometimes have a "wtf" reaction coming from Internet protocols or kernel concerns, and while there are some wtf-worthy details in any piece of software, lots of the time people just don't understand the problem. Just as GNOME and KDE both took years to understand it and flailed around with all those protocols that didn't work out well.
Still, it's a fact that DCOP back then felt much nicer and more humane (I wouldn't know about speed). I haven't used Linux in a while so I honestly don't know now.
you seem to do it right: most level-headed, most informative. thanks.
It was, iirc, supposed to be a place for KDE and Gnome to hammer out some cooperative issues, so that programs related to each project would coexist better.
These days it seems like Gnome (or maybe i should say Red Hat?) is running the place, with KDE doing its own thing and glancing over the fence from time to time.
What actually happened is that the high-level wrappers didn't get written for a long time because libdbus was just good enough that people didn't bother to work on alternatives. So that sucked, but it does seem to have finally been sorted out and libdbus is now on the way out AIUI.
From DBUS' own (old) FAQ:
> D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus should not be more complex for programmers. The additional complexity of D-Bus arises from its separation of object references vs. bus names vs. interfaces as distinct concepts, and its support for one-to-one connections in addition to connections over the bus. The libdbus reference implementation has a lot of API to support multiple bindings and main loops, and performs data validation and out-of-memory handling in order to support secure applications such as the systemwide bus.
> D-Bus is probably somewhat slower than DCOP due to data validation and more "layers" in the reference implementation. A comparison hasn't been posted to the list though.
IMHO DBus suffers from the kind of overengineering that's been endemic in Desktop Linux in the last few years: DConf/GSettings (as a less flexible, IMHO unneccessary replacement for GConf), PulseAudio and NetworkManager (initially really bad, now work nicely, as long as you don't have to debug problems...), all the *Kit stuff, systemd, and so on. For me, libraries like this don't really solve problems on average, but cause regressions.