On Fri, Jul 31, 2020 at 11:26:28AM -0400, John Snow wrote: > > The long answer is that as a general philosophy I'm in favour of agressively > > eliminating anything that is custom to a project and isn't offering an > > compelling benefit over a functionally equivalent, commonly used / standard > > solution. > > > > I agree as violently as I know how. The purpose of this is not for us, it's > for the ecosystem. > > I saw the critique that we still use JSON-ish for the runtime QMP protocol, > and moving the QAPI IDL to a standard wouldn't remove all instances of a > custom format from our tree.
I'd consider the runtime protocol separately. In terms of what's on the wire, we use genuine JSON format. The runtime problem is simply that JSON standard is useless when it comes to integers, leaving behaviour undefined in the standard if you exceed 53 bits of precision. So there's no way to reliably parse unsigned 64-bit integers. Given that QEMU needs to pass uint64 values, JSON was simply the wrong choice of format for QMP. There's a 3rd aspect which is our source code that deals with JSON, where we defined some JSON extensions to make it easier for C code to construct JSON documents for sending over the wire. Back when we did this, it was a reasonably good idea as no obvious alternative existed for this problem. Today, I would just suggest using GLib's GVariant feature, which solves the same problem for GLib's DBus APIs. It is a shame we didn't just use DBus back in the day as that's a well specified, simple protocol that would have done everything we needed, including the ability to actually represent integers reliably. We would be able to trivially talk to QEMU from any programming language, and use common DBus code-generator tools instead of writing code generators ourselves. I wish that libvirt had picked DBus all that time ago too, instead of creating our own RPC based on XDR, which is 95% identical to what DBus provides but with a massive maint burden for ourselves. Back then DBus didn't seem like it was good enough as it didn't offer TLS or SASL support and that looked like such a big deal. With hindsight the right answer was to add TLS + SASL to DBus, and not invent our own protocol. We would have lacked TLS/SASL support in libvirt for 6 to 12 months or so, but then would have had 10 years benefitting from the DBus ecosystem. Life would have been much easier for mgmt tools using libvirt too, as they could have used native DBus APIs instead of having to use the C libvirt.so client. This is one of my biggest regrets with libvirt's architecture, and even ater 10 years it is still probably worth fixing this mistake and adopting DBus. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|