“Bus” for Bus
I am a bit grumpy right now, so please bear with my ranting…
Do you know what the “Bus” in DBus stands for? It stands for “Bus”. And did you know that the DBus specification defines a “Message Bus”? So it’s a bus on which you can do message passing. But why is it that we try to hide this away trying to fool developers into believing that it’s really an RPC system? – It’s not! Let me put in in italics for you: DBus is a message passing system.
DBus is a wicked cool, relatively easy to use, message bus with all kinds of fancy name-, life cycle-, message matching-, and what-not management. Not an RPC system from the eighties! You can use it as such – with great success I might add, but it’s much more than that.
We as the Gnome community are leaving the olde Corba/Bonobo days behind us. Let’s not blindly choose the next hot RPC system and pretend it’s any better. Let’s embrace the new world order. The massive success of the HTTP protocol, increasing momentum of functional (and/or functional+object oriented) platforms such as Erlang, Scala, Haskell and F#, and the ever growing adoption of Actor-model like APIs is a sure testament to the fact that we are moving into the era of message passing (I would claim that we are, in fact, already there). We have a powerful message passing framework at our hands – let’s make the most of it.
Phew. I feel better already. Thanks for listening 
Tags: dbus, grumpy, message passing, rant
March 18th, 2010 at 3:02 pm
DBus is old hat – all the cool kids now use web services instead. I’ll wager that with increasing use of the cloud (and therefore the need to interact with both local and cloud) that web services will likely replace the olde bus in the not so distant future. HTML 5 will use it too so and that could replace GTK/QT if done right. i also feel dbus has some technical shortcomings (no null value support, no enums etc)
Functional languages are really old and are serious old hat and difficult to maintain projects written in them. With the need to support threads safely and sanely async message passing will be retained behind the scenes but the front of any language will likely remain procedural (with the odd lambda syntax) although with vala style sugar masking the message handling
March 18th, 2010 at 4:46 pm
@Jamie: If you mean that all apps are webapps running in a browser, then indeed DBus will not play a big role. However let us not forget that DBus is used in stuff like X and Upstart as well. I also have a hard time seeing webapps completely taking over for at least 5-10 years.
The lack of null support is a bitch I give you that. However let’s see what happens when GVariant goes more mainstream. It’s support for maybe-types could eventually lead to introduction of the same concept in the DBus wie format.
DBus also have the huge advantage over HTTP that it is a bus (and a life cycle manager).
Regarding functional languages I’d hate to start that flamewar
However I am also more keen on emphasizing that cross breed languages like F# and Scala (and to some degree Vala) are more likely to win followers than purely functional ones imho. But it also depends on which frameworks there are for these runtimes. That said I still think there is a wonderful mathematical beauty in purely functional languages.
March 18th, 2010 at 5:23 pm
@kamstrup: whilst web apps are undoubtedly the future, I still reckon web services should replace the session dbus if only because it makes more sense in a cloud oriented environment. DBus will certianly live on as the system bus for the kernel/X/hardware but its role as a sesison bus in apps will likely be marginalised by a desire to integrate more with the cloud (prior to the emergence of a web app based future)
EG take the concept of first class objects like a contact or person and it should be clear that only a web service could represent such an entity wherever it be (be it local or on the cloud).
Web services can have life cycles too and a web service/dbus session bridge is something that would make a lot of sense too IMO
March 19th, 2010 at 1:28 am
@Jamie: “EG take the concept of first class objects like a contact or person and it should be clear that only a web service could represent such an entity” – why? This seems perfectly doable over DBus. We’d have to escape the RPC-shackles we have put on our selves – but that’s not a big issue. Simply say that fx. contacts are represented by objects with path /org/gnome/contacts/ – no mention of bus name or interface, simply use DBus match rules to interact with it.
And “Web services can have life cycles too” – what apart from a login has state in web services? Is rule number uno of web services not that they should never have state?
Anyway if you want to use web services as a bus-like thing you have to keep connections open to them so they can signal you and what not. Otherwise the webservices would need a boatload of state so that you could do active polling on them. Both options sounds like a steep price on system resources..?
March 19th, 2010 at 6:19 am
God I hope web apps don’t take over. I hate web development so much. Personally I don’t see why people seem so keen to integrate technologies like css into the desktop, I mean really? css? It’s a freakin pain in the ass. There are good reasons for all these high level wrappers of css, and they all orient around it being trashy. We need to take a harder look at these problems I think, rather than deciding on half baked solutions because they already exist.
End web development / css rant.
March 19th, 2010 at 4:07 pm
jamie: HTTP for local IPC doesn’t sound very efficient? I imagine a lot of overhead compared to D-Bus? Or am I just being prejudiced?
March 20th, 2010 at 7:53 am
@Anders: Well – the raw DBus protocol is pretty efficient, by design, compared to HTTP. One can indeed write a light, extremely efficient, HTTP server intended for desktop – not server use, That may outperform DBus, since afaik the dbus-daemon has not been optimized a lot.
But if we keep the question to “Can we write a light, efficient, HTTP server for the desktop”, then the answer is undoubtedly “yes”. But if we really really want to make it light and efficient then it’ll take a lot of work. The question is much harder when we want to compare it to DBus
March 20th, 2010 at 12:32 pm
@kamstrup: I see. Is this not what Cherokee and other ‘light’ webserver projects are trying to achieve? Perhaps they are not focused exclusively on the desktop..
If only I had time in between talking out of my ass, I’d do something about it
March 20th, 2010 at 4:35 pm
@Anders: TO be honest – I don’t know. I’d actually expect that something more in spirit of a HTTP proxy would more suitable than a full blown server. Web servers do quite a lot more than parse HTTP headers. If we primarily want to use it for local messaging and at times as a message-bridge to the web, then something akin to a light proxy server might be enough.