On Tue, Jul 02, 2013 at 01:27:32PM -0500, Anthony Liguori wrote: > 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 like this solution, but QObject is not a defined type in qapi-schema.json, so we can't assign qobj to return data. We also need to do "post-processing" to provide prolific meta-data to management.
# { 'command': 'query-qmp-schema', 'returns': ['QObject'] } > I don't understand what all this talk of "post-processing" is. When management gets the raw jaso string, they could not directly use, post-processing might be: 1) revert the whole schema by itself, replace defined type by complex json 2) process the '*' before typename 3) process json string to get type(command/event/type...),name(command name, type name, event name), data, returns one by one. 4) etc > Regards, > > Anthony Liguori -- Amos.