"Daniel P. Berrange" <berra...@redhat.com> writes: > On Fri, Sep 11, 2015 at 09:02:15AM +0200, Markus Armbruster wrote: >> Michael Roth <mdr...@linux.vnet.ibm.com> writes: >> >> > Quoting Markus Armbruster (2015-09-07 05:16:41) >> >> A new test-qmp-input-visitor test case feeds its result for both >> >> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a >> >> QmpInputVisitor to verify it actually conforms to the schema. >> >> >> >> New QMP command query-qmp-schema takes its return value from that >> >> variable. Its reply is some 85KiBytes for me right now. >> >> >> >> If this turns out to be too much, we have a couple of options: >> >> >> >> * We can use shorter names in the JSON. Not the QMP style. >> >> >> >> * Optionally return the sub-schema for commands and events given as >> >> arguments. >> >> >> >> Right now qmp_query_schema() sends the string literal computed by >> >> qmp-introspect.py. To compute sub-schema at run time, we'd have to >> >> duplicate parts of qapi-introspect.py in C. Unattractive. >> >> >> >> * Let clients cache the output of query-qmp-schema. >> >> >> >> It changes only on QEMU upgrades, i.e. rarely. Provide a command >> >> query-qmp-schema-hash. Clients can have a cache indexed by hash, >> >> and re-query the schema only when they don't have it cached. Even >> >> simpler: put the hash in the QMP greeting. >> > >> > Would probably be easier for management to build up their own structure >> > for querying caps, so I think a computed hash seems best. But I don't >> > think either is something that couldn't be added later if need be. >> >> I also think a hash is the way to go, and I'd like to provide one early, >> but I don't want to delay this series for it. > > FWIW, libvirt already caches the results of its query of QEMU and will > only re-query QEMU if the timestamp of the QEMU binary on disk has > changed, or if libvirt itself has changed. Also when querying the QEMU > capabilities there are quite a few commands we run, we want to cache > the full set, not just query-qmp-schema, so we can avoid launching QEMU > at all. o at least from Libvirt's POV, I don't think we have a need for > a hash of query-qmp-schema.
Noted.
