[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] full introspection support for QMP

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] full introspection support for QMP
Date: Tue, 02 Jul 2013 11:11:07 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

On 07/02/2013 11:06 AM, Anthony Liguori wrote:
>> Because qapi-schema.json requires further parsing.  For example, how is
>> a client supposed to know that '*foo':'int' means that there is an
>> argument named 'foo' but it is optional?  The rule of thumb with QMP is
>> that if you have to post-process JSON output, then the JSON was not
>> designed correctly.
> Then we should fix qapi-schema.json.

> One reasonable compromise would be:
> { "command": "foo", "arguments": { "name": "str", "id": "int" },
>                     "optional": { "bar": "bool" } }
> Then libvirt only has to test 'does command["optional"] contain key
> "bar"' to test for an optional parameter.

Yes, that might be a reasonable compromise - at least that way, the
optional parameter names are listed directly, and libvirt doesn't have
to probe every single parameter to name to see which begin with '*'.

> Although to be honest, '*bar' in command['arguments'] is reasonable too

It may be reasonable, but it forces every QMP client to reimplement the
post-processing step, rather than presenting the parameter names already
in isolation.

Food for thought - suppose we wanted to start expressing in the .json
file what the default value is for any parameter that is listed as
optional?  What representation is most compact for that purpose, while
still being valid JSON and not requiring QMP clients to reimplement

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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