So the advantage is supposedly that it's extremely simple (just NUL-terminated JSON over a stream socket!) except that, when you look at the spec, it's actually not that simple, so they have only implemented a subset, and then they have also extended it with more features, so in the end it's not simple and not really even Varlink?<p>And it's now 40% slower at serialization and it can't embed binary data, but that's OK because now "web native folks" can be OS infrastructure developers without learning a new format? Except the interface definition format, which is not JSON, but for some reason the wire format has to be.<p>And all the D-Bus stuff, with all the problems enumerated in the presentation, will still be kept around, so we'll have D-Bus + systemd's "quite different" D-Bus variant + Varlink + systemd's Varlink variant that "does not bother with" the spec but has "additions", all at the same time.<p>It doesn't sound "extremely simple" to me.
Why bother with Varlink IPC, and why now?<p>The Varlink IPC has been around for a while, but recently we started using it heavily in systemd. In this talk I'd like to explain what Varlink IPC is, and why we are now adopting it so heavily. And I also want to explain why I think that Varlink is a good candidate as IPC of choice for any Linux software, both low-level and higher-level. We'll compare it with D-Bus in particular, and highlight where it shines (and where it doesn't shine so much).