Re: [PATCH] schemas: Add vim modeline

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

Yes.

Fine print: QMP accepts (but does not emit) minor extensions[*].  RFC
8592 actually permits this: "A JSON parser MAY accept non-JSON forms or
extensions."  This is due to lazy implementation, not due to an actual
need.  We could deprecate and remove.

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

To be precise: "An implementation may set limits on the range and
precision of numbers."  Not quite undefined behavior.  Useless all the
same.  There are more interoperability pitfalls due to JSON's
notoriously useless minimal requirements.  Range of numbers is the most
relevant one, because so many implementations set useless numeric
limits, and there is no good way to work around the issue.

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

Example: qmp_error_response() uses the interpolation extension to safely
insert values into a JSON syntax tree.

    rsp = qdict_from_jsonf_nofail("{ 'error': { 'class': %s, 'desc': %s } }",
                                  QapiErrorClass_str(error_get_class(err)),
                                  error_get_pretty(err));

Two extensions, actually:

1. Interpolation: tokens starting with % get replaced by the
   corresponding variable argument converted to a QObject.

2. Single-quoted strings to avoid leaning toothpick syndrome.

Without interpolation, we'd have to construct the tree by hand, like
this:

    error = qdict_new();
    qdict_put_str(error, "class", QapiErrorClass_str(error_get_class(err)),
    qdict_put_str(error, "desc", error_get_pretty(err));
    rsp = qdict_new();
    qdict_put(rsp, error);

Much harder to read even for such a simple example.

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

Water under the bridge.

[...]

[*] Single-quoted strings and \' in strings.