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
signature.asc
Description: OpenPGP digital signature
