Looks to me like DBus is actually pretty good and just needs some good implementations, some bug reports and some active contributors. I'm not super familiar with non-server applications in linux, but isn't DBus also in widespread use?
Most linux server apps I know communicate through the filesystem by leaving a .pid,.lock and/or a .sock somewhere and then setting up a custom channel using a handle to that. It feels kind of hacky, but at least you get to control the crappiness.
kdbus actually supports a whole load of fairly sensible communications models, with a reasonably simple API, and ditches the horrible bits of dbus. It's a shame that it's (unnecessarily IMO) bound up in controversy.
It doesn't seem very general purpose unless there are also non kernel implementations, and you can't sanely remote it as it relies on the kernel for authentication.
Its purpose is single host communication. If you assume a single host then you don't have to deal with distributing computing problems at all.
Not sure why having non-kernel implementations is a problem. Is the fact that there is no non-kernel implementation of Unix sockets / TCP/IP / filesystems / name-most-other-Linux-kernel-features a problem for you?
BTW I don't especially care about kdbus, but I do hate that there are no good, featureful communication primitives in Linux.
The article was looking for multihost too which is why I mentioned it.
There are some non kernel sockets implementations, but it is less of an issue as every kernel implements them, but kdbus is not implemented anywhere yet. It is also not possible to implement correctly in userspace as the security guarantees rely on a kernel, which is inconvenient. It is unlikely eg FreeBSD will ever implement it.
The problem with DBus is that it's been around for ages now and still most developers say they support it because they have to, not because they like it. Basically, it's not going to get much better than it already is, or by now it would have.
Providing an easy-to-use interface is the job of D-Bus client libraries, not the protocol itself. Client libraries are still a wild frontier, not at all settled.
I thought sd-bus was considered a good D-Bus client library? Haven't had the need to try it out myself, but the name has been popping up recently when dbus has been discussed.
ITts a lot better. I've ported libdbus-1 code to sd-bus and in practise I saw 100s of lines are replaced by about 20, with better error reporting on top of it.
Most linux server apps I know communicate through the filesystem by leaving a .pid,.lock and/or a .sock somewhere and then setting up a custom channel using a handle to that. It feels kind of hacky, but at least you get to control the crappiness.