Re: oh well
> Then I haven't been able to find any sensible reason for it. I mean why should desktop applications be able to send messages to each other?
Are you really asking why a desktop environment should have inter-process communications (IPC), or did I just misunderstand you?
> since it's implemented as a library applications link against, there is no easy way to get rid of it. If it was implemented as a set of separate programs which would be executed by the software wanting to send or receive messages, it would be a whole different game.
That is exactly how DBus is implemented. The library that you mention (libdbus) is just there to abstract away the details of sending and receiving messages. You can most certainly still use DBus without it, would you be so inclined (you'll be in for some serious pain), and programs linking against libdbus will still work in the absence of a DBus session or daemon if they have been designed correctly and IPC is not a core requirement.
I should know as I have written software using DBus. Examples of what I have done are equipment monitoring clients (will tell anyone interested if certain equipment that your computer communicates with starts to fail or logs certain events), and also for an application that performs scientific computations--other programs can request the results directly from the application via DBus, saving the user from having to start a front-end, input the data, extract the results, and feed them back to the other app. More trivial things include logging out users from the intranet portal when the screensaver starts on a public kiosk (people will often forget or not have time to log out--this being at a fire station) and stuff like that.
It seems to me that your gripes are with how programs use IPC, rather than with DBus itself.
Biting the hand that feeds IT
