Re: [PATCH] schemas: Add vim modeline

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 31/07/20 17:44, Daniel P. Berrangé wrote:
>> 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.
>
> JSON's 53-bit precision was not part of RFC4627, which was the JSON
> specification in 2010.  They say hindsight is 20/20, but referring to
> RFC7159 which would come 4 years later is rewriting history, not hindsight.

RFC 4627's original sin:

    4.  Parsers
    [...]
    An implementation may set limits on the size of texts that it
    accepts.  An implementation may set limits on the maximum depth of
    nesting.  An implementation may set limits on the range of numbers.
    An implementation may set limits on the length and character contents
    of strings.

Giving license to set limits is not a sin, absence of minimal limits is.

Became an actual problem only when many implementations followed the
early JavaScript implementation(s), which had inherited JavaScript's
quick-and-dirty approach to numerical towers: double should be enough
for anybody.

>> 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.
>
> Many years ago actually I tried replacing QObject with GVariant.  I'm
> pretty sure the code for that experiment is lost but it took me just a
> couple days so it could be redone.  The only issue was that QObjects are
> mutable so some instances of QString had to be replaced with GString.
>
> (A small part of it was merged as commit
> 9bada8971173345ceb37ed1a47b00a01a4dd48cf for unrelated reasons).
>
>> 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.
>
> Not really, DBus doesn't provide the extensibility that we get from
> optional arguments in commands and optional fields in structs.

Enables compatible evolution of interfaces, which has been a massive win
for us.

>                                                                 Again,
> we may discuss the QMP protocol itself,

We can discuss everything, but please not everything in the same thread.
This one is / tries to be about the QAPI schema language.

>                                         but JSON *was chosen for a reason*.

In our field, dissing prior technical choices without making an effort
to understand the tradeoffs that led to them is an ancient tradition :)