[Top][All Lists]

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

Re: qmp-shell for GSoC/Outreachy?

From: Eric Blake
Subject: Re: qmp-shell for GSoC/Outreachy?
Date: Fri, 7 Feb 2020 15:31:23 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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.

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.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

reply via email to

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