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?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
