Eric Blake <ebl...@redhat.com> writes: > On 07/02/2013 11:01 AM, Paolo Bonzini wrote: >>>> 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. >> >> How would the schema look like after this "one-time pass"? >> >> This: >> >>> [ >>> { "name": "protocol", >>> "type": "str" }, >>> { "name": "fdname", >>> "type": "str" }, >>> { "name": "skipauth", >>> "type": "bool", >>> "optional": true }, >>> { "name": "tls", >>> "type": "bool", >>> "optional": true } >>> ] >> >> Looks quite awful for a human to write and read. > > Which puts us back in favor of my original argument that keeping > qapi-schema.json compact for human use,
qapi-schema.json is not "for human use". It's consumed by QAPI. It happens to be reasonably human readable but that's just a happy coincidence and because we document and format the heck out of it. > while expanding the QMP output > to be verbose for machine use, is probably what we'll have to live with. > While it is easy to document shortcuts that the qapi parser can use > when converting .json to code, it is harder to require that all other > QMP clients must implement those same shortcuts, instead of having > things already directly represented. qapi-schema.json is valid JSON except for the # style comments. Those are trivial to remove and we could simply post process it. Heck, if you use json_parser to parse the file, you'd end up with a list of QObjects that could be returned directly via QMP. I don't understand what all this talk of "post-processing" is. Regards, Anthony Liguori > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org