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

[Eric Blake <eblake@redhat.com>]

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

On 07/02/2013 09:39 AM, Daniel P. Berrange wrote:
>>> 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.
> 
> Arguably that rule of thumb would apply equally to the QEMU
> build scripts which already parse qapi-schema.json. It could
> be possible to normalize qapi-schema.json somewhat to remove
> this 2-stage parsing if we went down this route.

Indeed, I wouldn't mind a one-time pass over qapi-schema.json to make it
follow a more rigid format if that made it easier to use it as-is with
less post-processing.  It won't be very nice to backport such a
conversion, but I don't know how much distros are planning on
backporting introspection in the first place.

> 
> I'm finding it hard to clearly see what the 2 different proposed
> data formats look like against each other. Can someone give some
> examples, showing the data that would need to be parsed in each
> format, for a couple of examples.

My proposal (but not quite what was implemented in _this_ version of
Amos' patch) has been:

qapi-schema.json:

{ 'command': 'add_client',
  'data': { 'protocol': 'str', 'fdname': 'str', '*skipauth': 'bool',
            '*tls': 'bool' } }

My proposal:


=> { "execute": "query-qmp-schema",
     "arguments": { "name": "add_client" } }
<= { "return": [
     { "name": "add_client",
       "type": "command",
       "data": [
         { "name": "protocol",
           "type": "str" },
         { "name": "fdname",
           "type": "str" },
         { "name": "skipauth",
           "type": "bool",
           "optional": true },
         { "name": "tls",
           "type": "bool",
           "optional": true }
       ] } ] }

Note that one other benefit of breaking out "optional" into its own dict
member: we are free to expand the dict to add new members, such as a
'*default':'str' member (present when "optional":true, and with the
stringized value of the default value used if "name" is not present).
Of course, to be able to express a default value, we already have to
modify the syntax stored in qapi-schema.json in the first place, which
takes us back to the argument of a one-time conversion of the .json file
to actually use a more formal typing system in the first place.

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