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

[Anthony Liguori <aliguori@us.ibm.com>]

Eric Blake <eblake@redhat.com> writes:

> 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
>> IMHO.
>
> 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
> post-processing?

We won't do that.  It would be way too hard to retrofit it for very
little value.

Regards,

Anthony Liguori

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