On 6/9/21 7:56 AM, Markus Armbruster wrote:
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.
What ideas did you have for a cache key? We don't need to uniquely
identify every instance or even every binary.
I suppose we could use an md5/sha1 checksum of the QMP introspection output?
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.
It is and I agree. I have been pushing Niteesh to complete the simplest
possible prototype imaginable, but I believe he's identified having help
text as something he'd really like to see, so I am investigating those
concerns.
I do not think we'll actually be able to fully implement it start to
finish, but it may be possible that we can implement a kind of "mockup"
x-help command that has a few hardcoded things we can use to prototype
the feature in the TUI.
I will keep scope creep in mind, we will pick and choose our battles. I
am hell-bent on having *anything* checked into the tree by August, and I
know that can be a longer process than we expect sometimes. I know this
means keeping it small.
--js
