4 ms·

Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implem

by hp 12y ago

Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used. 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.

guard-of-terra 12y ago
I'm not talking about runtime speed or latency, rather about development speed.
- hp 12y ago
  I should have mentioned here earlier, the original thought with dbus was that nobody would use libdbus directly; KDE would use an API more or less exactly like DCOP and GNOME would use soemthing like gdbus. For that reason, libdbus was lowlevel and flexible in a way that made it annoying to use - convenience API in libdbus would have been bloat. 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.
toyg 12y ago
> Adoption speaks for itself 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.
- digi_owl 12y ago
  That seems to be the story of freedesktop.org in total. 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.
  - johnny22 12y ago
    i really don't see how you're getting that impression. We've seen cooperation on shared menus, mime types, dbus, and wayland (among others).
- hp 12y ago
  In creating dbus, I talked to a bunch of developers at KDE, specifically those who worked on Qt and DCOP, about their requirements. Then I met the requirements they said I had to meet for them to use dbus. I did the same for developers at GNOME. Because dbus met the requirements that the actual decision-making developers had, and allowed them to do useful things, it was adopted. 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.
  - toyg 12y ago

by hp 12y ago

guard-of-terra 12y ago

I'm not talking about runtime speed or latency, rather about development speed.

hp 12y ago
I should have mentioned here earlier, the original thought with dbus was that nobody would use libdbus directly; KDE would use an API more or less exactly like DCOP and GNOME would use soemthing like gdbus. For that reason, libdbus was lowlevel and flexible in a way that made it annoying to use - convenience API in libdbus would have been bloat. 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.

toyg 12y ago

> Adoption speaks for itself 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.

digi_owl 12y ago
That seems to be the story of freedesktop.org in total. 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.
- johnny22 12y ago
  i really don't see how you're getting that impression. We've seen cooperation on shared menus, mime types, dbus, and wayland (among others).
hp 12y ago
In creating dbus, I talked to a bunch of developers at KDE, specifically those who worked on Qt and DCOP, about their requirements. Then I met the requirements they said I had to meet for them to use dbus. I did the same for developers at GNOME. Because dbus met the requirements that the actual decision-making developers had, and allowed them to do useful things, it was adopted. 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.
- toyg 12y ago