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