Re: [PATCH] schemas: Add vim modeline

["Daniel P. Berrangé" <berrange@redhat.com>]

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 :|