[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qmp-shell for GSoC/Outreachy?

From: Markus Armbruster
Subject: Re: qmp-shell for GSoC/Outreachy?
Date: Sat, 08 Feb 2020 08:34:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.


The complexity enters through the 'any' backdoor.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]