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.
>
> 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
