John Snow <js...@redhat.com> writes: > On 6/8/21 11:01 AM, Markus Armbruster wrote: >> John Snow <js...@redhat.com> writes: >> [...] >> >>> A challenge will be where to pull the help text from. The QEMU server >>> is not capable (today) of sending help information over the QMP socket >>> itself. >>> >>> We will need to implement a QMP command inside of QEMU directly that >>> is capable of delivering this information to the client so that it can >>> render it. >>> >>> Since not all versions of QEMU will have this feature, the qmp-shell >>> will need to be able to gracefully deal with the lack of help text, >>> displaying an error indicating that this version of QEMU does not have >>> help information compiled into it. >> The doc text is bulky: my bld/docs/manual/interop/qemu-qmp-ref.html >> is >> 1.7 MiB and growing. Less lavish markup results in smaller data. We >> may want to store it compressed, or load it on demand. We might even >> have to make it compile-time optional for some use cases. >> > > ACK, understood. > > raw QAPI directory, including only the json files, is "only" 551.3 kB. > > I assume we can compile help text to something json (or json-like) and > then compress it. Perhaps we could compile something like > qapi-help-introspect.json.tgz and load it on-demand from the QEMU > binary when help text is requested. > > We could prototype under the experimental QMP command x-help, and > limit it to sending help for just one command at a time to limit data > transfer. > > The client could cache the information. (Against what kind of an > identifier? Can QEMU report some kind of token that uniquely > identifies its binary or uniquely identifies the set of QAPI commands > it supports?)
I proposed something like it to permit QMP clients cache query-qmp-schema output. Libvirt didn't want it, so it never got beyond the idea stage. > This has the potential to exceed our capacity this summer, but a > prototype experiment might be helpful to inform future work anyway. Beware of the risk that comes with shiny stretch goals: loss of focus. I believe this is actually this GSoC project's main risk.
