Hmm, so it would not work on systems without DBus? If that is unix app, why not just use unix socket?
While bus-based publish-subscribe paradigm may have some merit in desktop setting, for direct control the client-server is much more straightforward, and in this case these answers are easy. Each instance owns one socket, if there are multiple instances and not a default one, a client needs to know which to connect to (as they are generally not interchangable), and even if they are, a client can just enumerate sockets and open the first alive.
> "how to serialise and version the remote requests"
These issues are irrelevant for connection-oriented and reliable unix sockets.
> Dbus solves a lot of that without (effectively) designing your own custom underspecified version of half of dbus.
Not really. Connection-oriented client-server solution is just much simpler that dbus and offers some advantages like implicit state associated with connection. Dbus makes things much more complicated and then solves some of these complications.
This comment is really confusing to me. It's not irrelevant, you need to serialize the messages somehow. And if you ever decide you want to add some new messages, then you have to deal with versioning. It's not simple. What you have described is just a cut down implementation of D-Bus. And you are leaving some other things out:
- race-free name resolution, the solution you described has a lot of race conditions
- message ordering, the best way to do this reliably across 3 or more processes is to use a bus-based method
- security, auditing, rate limiting, i.e. how does a system admin manage your service. This is all solved with D-Bus
I've seen lots of complaining about D-Bus over the years about how it's "too complex" but everything in it is there for a reason, and I've never seen anyone actually able to make a simpler design that works as well. If you implement all the stuff I just talked about then your solution will be about as complex as D-Bus. So in terms of message buses I actually think it is quite simple compared to other things like ActiveMQ. Please stop implementing ad-hoc protocols over a socket unless you have a really good reason to do that, it drives me nuts to see that stuff getting deployed and people going through the motions fixing the same bugs over and over. At the very least you could use protocol buffers, or use ASN.1, or re-use the D-Bus wire format, or do anything besides rolling your own.
export DBUS_SESSION_BUS_ADDRESS="no"
to avoid Firefox from starting dbus, which is a Linuxism ported to BSD just to allow people to execute some applications. That works fine for me.
So since this is removed and Firefox is the only app that I use which needs dbus, I wonder if I will be required to use yet another useless (ie: not needed by OpenBSD) process just to use Firefox.
It's also cross-platform, and runs natively on OpenBSD, NetBSD, and FreeBSD. It does not leverage a compatibility layer, and depending on it is in no way comparable to requiring an emulation layer like WINE.
Gnome/Kde compositors don't use d-bus either, they instead use wayland extensions for control (since both the compositors and clients have to implement wayland already anyway, this is easier than using d-bus).