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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Jul 02, 2013 at 09:28:51AM -0600, Eric Blake wrote:
> On 07/02/2013 08:51 AM, Anthony Liguori wrote:
> > Amos Kong <akong@redhat.com> writes:
> > 
> >> Introduces new monitor command to query QMP schema information,
> >> the return data is a nested dict/list, it contains the useful
> >> metadata.
> >>
> >> we can add events definations to qapi-schema.json, then it can
> >> also be queried.
> >>
> >> Signed-off-by: Amos Kong <akong@redhat.com>
> > 
> > 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.

> > It's JSON already and since QMP is JSON, the client already has a JSON
> > parser.  Adding another level of complexity doesn't add much value IMHO.
> 
> qapi-schema.json is not quite JSON, in that it has #comments that we'd
> have to strip before we attempted a trick like this.  I've also been the
> one arguing that the additional complexity (an array of
> {"name":"str","type":"str","optional":bool"}) is better for libvirt in
> that the JSON is then well-suited for scanning (it is easier to scan
> through an array where the key is a constant "name", and looking for the
> value that we are interested in, than it is to scan through a dictionary
> where the keys of the dictionary are the names we are interested in).
> That is, the JSON in qapi-schema.json is a nice compact representation
> that works for humans, but may be a bit TOO compact for handling via
> machines.

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.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|