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 08:51 AM, Anthony Liguori wrote:
>> Amos Kong <akong@redhat.com> writes:
>> 
>>> Introduces new monitor command to query QMP schema information,
>>> the return data is a nested dict/list, it contains the useful
>>> metadata.
>>>
>>> we can add events definations to qapi-schema.json, then it can
>>> also be queried.
>>>
>>> Signed-off-by: Amos Kong <akong@redhat.com>
>> 
>> Maybe I'm being too meta here, but why not just return qapi-schema.json
>> as a string and call it as day?
>
> 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.

>> It's JSON already and since QMP is JSON, the client already has a JSON
>> parser.  Adding another level of complexity doesn't add much value IMHO.
>
> qapi-schema.json is not quite JSON, in that it has #comments that we'd
> have to strip before we attempted a trick like this.  

Pretty easy to filter that out...

> I've also been the one arguing that the additional complexity (an array of
> {"name":"str","type":"str","optional":bool"}) is better for libvirt in
> that the JSON is then well-suited for scanning (it is easier to scan
> through an array where the key is a constant "name", and looking for the
> value that we are interested in, than it is to scan through a dictionary
> where the keys of the dictionary are the names we are interested in).
> That is, the JSON in qapi-schema.json is a nice compact representation
> that works for humans, but may be a bit TOO compact for handling via
> machines.

But adding a bunch of code to do JSON translation just adds a bunch of
additional complexity.

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.

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

Regards,

Anthony Liguori


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