Eric Blake <ebl...@redhat.com> writes: > 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.
We consume the schema in QEMU. No reason for us to consume it in a different format than libvirt. We're all after the same thing. Regards, Anthony Liguori > >> >> 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. I really think that we want schema introspection to return the exact content of qapi-schema.json. I don't think we need an overly verbose schema though and I don't really understand why { 'name': 'tls', 'type': 'bool', 'optional': true } is better than { '*name': 'bool' } Regards, Anthony Liguori > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org