I'm writing a "fake" QMP server for the purposes of creating unit tests for the python QMP library. In doing so, I am left with some esoteric questions:
(1) qemu-spec.txt, section 2.4.2, "error":
The format of an "error response" is:
> { "error": { "class": json-string, "desc": json-string }, "id": json-value }
For the purposes of naming internal types in the QMP library, does the "error" object value have a canonical type name? It's not defined in QAPI that I can see.
(2) qemu-spec.txt, section 2.2 "Server Greeting":
The greeting message format is:
> { "QMP": { "version": json-object, "capabilities": json-array } }
>
> Where,
>
> - The "version" member contains the Server's version information (the format
> is the same of the query-version command)
The layout of the "version" object is not specified in the spec itself, though it does ask you to refer to the query-version command. Hypothetically, is an alternate implementation of QMP in a binary that is *not* QEMU allowed to change the layout of the "version" object (so long as it matched whatever format it had for a "query-version" command, also not mandated by the spec), or must it *always* conform to this precise layout?
(qapi/control.json):
> { 'struct': 'VersionInfo',
> 'data': {'qemu': 'VersionTriple', 'package': 'str'} }
If so, what should such a hypothetical client that is *not* QEMU do here? What version does it report for the "qemu" VersionTriple member? Can I report 0.0.0?
(3) Does the qmp-spec technically mandate any commands being available?
I believe that qmp_capabilities is definitively a requirement of the spec, but what about query-commands, query-version, or quit? Are they technically requirements of the QMP spec, or just requirements of QEMU?
Weird questions, I know.
--js