Re: qmp-shell for GSoC/Outreachy?

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 2/6/20 12:18 PM, Dr. David Alan Gilbert wrote:
>
>>>
>>> Pain points of JSON include having to count parenthesises and having to
>>> quote so bloody much.  Additional QMP pain points include long names and
>>> excessive nesting.
>>
>> Some other pet hates:
>>    a) Number formats are awful for our uses
>>    b) Lack of room for comments
>
> Both permitted in JSON5.  Converting valid JSON5 into the stricter
> JSON is lossy when it comes to comments, but as comments don't affect
> machine meaning, maybe all the more it requires is an argument to
> qmp_capabilities stating whether the rest of the session will stick to
> strict JSON or prefer JSON5.
>
>>> We could make quoting optional for certain string literals.
>
> Hmm - JSON5 makes quoting optional for keys in { key:value }, but not
> values.
>
> And one of the reasons why my QAPIfication of netdev was NOT committed
> was that the original code allowed both "item":1 and "item":"1" in the
> QemuOpts world, and we were torn on whether letting QMP accept both
> integer and string-that-parses-as-integer was acceptable.

I think we were in perfect agreement that netdev_add accepting strings
that happen to contain integers as integers is a flaw, we just couldn't
muster the nerve to correct it.

We've since become less dogmatic about maintaining bug compatibility.

>>>  Simple
>>> enough for literals that can only be a string, like abc.  For literals
>>> that could be something else like 123 or true, omitting quotes creates
>>> ambiguity.  When the schema accepts only one of the possible types, the
>>> ambiguity goes away.  Complexity stays, however.
>
> Do we even allow an alternate that permits both a string and a number
> at once? I thought you tightened qapi to reject that because of the
> potential for ambiguity.

Correct.

The complexity enters through the 'any' backdoor.