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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

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.

> 
> 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.  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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]