Re: GSoC Intro - TUI interface for QMP

[Markus Armbruster <armbru@redhat.com>]

John Snow <jsnow@redhat.com> writes:

> On 6/8/21 11:01 AM, Markus Armbruster wrote:
>> John Snow <jsnow@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.