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 <ak...@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 <ak...@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 :|
