Eric Blake <ebl...@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
