Earlier quoted context omitted.
What's wrong with old good Unix pipes?
The don't solve race conditions in peers trying to locate each other (surprisingly difficult). They don't solve a standardized marshaling format. They don't come with an implementation to integrate with main loops for event polling. They don't handle authentication (well, sort of). They have an inherent vulnerability in FD passing where you can cause the peer to lock up. You can get into deadlock situations in your m…
> The don't solve race conditions in peers trying to locate each other (surprisingly difficult).
Not even sure what you mean here. Are you talking about peer discovery? Because DBus won't help you there either--peers have to be aware of each other's DBus object paths before they can rendezvous. Similarly, two peers need to know where the common pipe is to rendezvous.
> They don't solve a standardized marshaling format.
Nor should they. There are a ton of ways to skin this cat in userspace, depending on what your application needs. Protobufs come to mind, for example, but there are others.
Why do you want the pipe to enforce a particular marshaling format? Does the pipe know what's best for every single application that will ever use it?
> They don't come with an implementation to integrate with main loops for event polling.
It's not the kernel's responsibility to implement the application's main loop. That's what libevent and friends are for today, if you need them.
> They have an inherent vulnerability in FD passing where you can cause the peer to lock up.
Last I checked, you pass file descriptors via UNIX sockets, not pipes.
> They don't handle authentication (well, sort of).
Depends on your application's threat model. The kernel provides some basic primitives that can be used to address common security-related problems (capabilities, permission bits, users, groups, and ACLs). If they're not enough, you're free to perform whatever authentication you need in userspace to secure your application against your threat model's adversaries.
It is unreasonable to expect the pipe to be aware of every single threat model an applications expects, especially since they change over time.
> You can get into deadlock situations in your messaging code if you aren't really careful about message sizes and when you order poll in/poll out.
It's not the pipe's fault if you don't use it correctly.
> They aren't introspect-able to see what the peer supports.
Peer A could use the pipe to ask peer B what it can do for peer A. Why do you want the pipe to do peer B's job?
> They make it super easy to not maintain ABI.
Nor does DBus. Nothing stops an application from willy-nilly changing the data it serves back.