Does anybody know why dbus exists? I’ve been wracking my brain trying to come up with a usecase for dbus that isn’t already covered by Unix sockets.
You want to remotely control a daemon? Use sockets. You want the daemon to respond to the client? Sockets. Want to exchange information in json? plaintext? binary data? Sockets can do it. Want to restrict access to a socket? Go ahead, change the socket’s permissions. Want to prevent unauthorized programs from pretending to be someone they’re not? Change the permissions of the directory containing the socket. Want network transparency? That’s why we have abstract sockets.
Plenty of well-established software uses sockets. Music player daemon uses sockets. BSPWM uses sockets. Tmux uses sockets. Pipewire uses sockets. Dhcpcd uses sockets. Heck, dbus itself relies on sockets!
For developers, using sockets is easy. I once wrote a program that interfaced with BSPWM, and it was a breeze. Dbus, on the other hand, not so much. I tried writing a Python script that would contact Network Manager and check the WiFi signal strength. Right off the bat I’m using some obscure undocumented package for interfacing with dbus. What is an introspection? What is a proxy object? What is an interface? Why do I need 60 lines of (Python!) code for a seemingly trivial operation?
So why do some developers decide to use dbus when they could just use unix sockets and save a lot of hassle for themselves and others?
Wouldn’t this also be possible with plain sockets tho? To continue with your example of music players, the current standard is MPRIS, which uses dbus. But in an alternate universe, the people behind MPRIS could just have decided that music players shall create sockets at
/run/user/1000/mpris/[player name]that all speak the same standardized protocol. If a player wanted to add functionality beyond MPRIS, it could accept nonstandard requests on its socket, or create a new socket altogether for extended control.I just don’t see how this would require any more coordination between developers than the current solution. And I don’t see how dbus can save you from having to “understanding every single […] app out there”. If anything, it adds the overhead of learning how dbus itself works, on top of how a specific app’s dbus interface works.
You keep using this phrase. Given time and money anything is possible. Technically we don’t need to use http - every server could implement their own standard using raw sockets. You then could download a simple client library for every site!
With a well defined dbus interface your application can talk to any number of applications that implement that interface. Even those you didn’t know about it at time of development. It provides a structure for ipc other than “go fetch libblah” and also “libblarg” and “libfloob” and read all of their docs and implement each one separately.
Many toolkits make dbus usage simple. It’s also introspectable so very easy to explore or generate bindings for dynamically.
It’s pretty nice to use IME.
this is the real answer - programming language bindings
Anything is possible with sockets… and that is a meaningless statement. It is like saying you can build anything with bricks. Technically true, but missing all the important details of how.
In an alternative universe we could have done so many things differently to solve the same problems. But we don’t live there and in our universe dbus was the attempt to solve that problem among others. And yes you can create a standardization for music players easily enough - but what about notifications, and everything else? DBus tries to be a generic interface anything can talk over at a logical level - rather that just being the basic way two process can physically send bytes between each other.