Hacker News Reader

Comment by baybal2 | Hacker News Reader

As I remember from more than a decade ago, the selling point of DBUS was that they were not trying to design a high performance message bus with sophisticated work mechanisms in spirit of Corba and Bonobo, but a small, flexible, and utilitarian one.

Things like implicit message buffering were deliberate design decisions.

View on HN

IMHO the problem with D-Bus was that it was never small and utilitarian. They decided (correctly) to ignore all the engineering effort involved in performance and scalability, and put all that overengineering into the API instead.

D-Bus code is basically unreadable, as not only are the bus names heavily scoped (java-style) to avoid collisions, but also the interface and method names. A tiny python (or whatever) script to invoke a single method on a well-known object should be a one-liner but in practice lives over 6-7 lines just due to verbosity.

D-Bus types are inexplicably low-level for a "utilitarian" IPC mechanism, leading to a bunch of type conversion to do simple things, and a ton of marshalling code in the core. Javascript has shown us how far you can get with just IEEE doubles and UTF-8 strings, yet D-Bus suffers with a type model that looks more like C.

Yeah, I used to have a whole bunch of shell scripts to automate KDE 3 apps via dcop and then when dcop was dropped in favor of dbus, the complexity of the latter system discouraged me from porting the scripts.

Whatever technical limitations dcop may have had, its command line was amazing: space separated words and a emphasis on discoverability made it a joy to use

qdbus is an almost adequate replacement for that. It's still more verbose and a bit more difficult to pass some arguments (this is all from memory) than dcop was, but it's servicable.

pydbus nicely abstracts away much of that: https://github.com/LEW21/pydbus

right, nobody was ever intended to use the raw protocol details directly... those details were intended to support an API that looked like using in-process objects (well, perhaps in-process objects with methods declared as 'async').

I wish they'd just build something simple, like AREXX. There's a reason AREXX ports were in almost every AmigaOS app: It was trivially simple to get started. The network effects were huge - pretty much any app was simple to automate. People to some extent built their apps as message pumps where input events (mouse, keyboard) triggered the same command hooks as AREXX messages, so every little piece of the app was scriptable.

If you wanted a more advanced API than AREXX could reasonably accommodate, it was easy enough to layer the more complex bits next to it.

The threshold for people to take full advantage of DBus is still too high. Maybe there's a need for something that complex for inter-application communication, but if so we'd also benefit from something simpler.

Maybe it's just a documentation failure... I don't know.

Reply on news.ycombinator.com