> But how many implementations currently exist? One.
I get your point about the inertia of there being one de facto implementation, but that’s not quite true. For example Glib’s DBus library contains an (almost) fully featured server implementation.
Anyway I’m not all that worried about the parser in particular. For one DBus wire format is well defined and pretty straightforward. This isn’t ASN.1. Actually it’s probably way simpler than modern DNS with EDNS, DNSSEC etc.
Isn't dbus-daemon and kdbus (in a couple of incarnations) different implementations?
kdbus was a different implementation, but I was under the impression that kdbus was "only" a routing implementation (though in truth that's all that dbus-daemon is anyway). However, kdbus never landed anywhere and it has been abandoned in favour of bus1: https://www.youtube.com/watch?v=6zN0b6BfgLY.
Saying "you can change it to whatever you want" is not a helpful thing to say. I understand your point (it's not "baked in" or wahtever) but you're not helping your cause by stating that "oh, we could just change this part of the protocol whenever we want and it would all just work". Because it gives an aura of instability and "we can move fast and break things" in my eyes (even though DBus has been around for a long time).
> DBus is a message-passing protocol. You can write it in anything you like.
The message passing daemon is written in C, and kdbus is a plan to put it inside the kernel (written in C). Just because "you can write it in whatever language you want" doesn't change that it is currently written in C, and I doubt that anyone is going to rewrite it in Rust any time soon.
Again, I understand that DBus is a protocol and an implementation and you can swap out the implementation if you want. But how many implementations currently exist? One. So currently the dangers of having custom binary formats in C is a valid concern even if you might be able to switch to some other implementation in the distant future.