Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote: >> >> >> On 1/23/20 2:01 PM, Daniel P. Berrangé wrote: [...] >> Well, sure. The context of this email was qmp-shell though, which is >> meant to help facilitate the entry of JSON commands so that you *can* >> indeed just forego the CLI/HMP entirely. >> >> If you are of the opinion that every user of QEMU should be copy/pasting >> JSON straight into a socket and we should delete qmp-shell, that's >> certainly a fine opinion. > > I think part of the pain of qmp-shell comes from the very fact that > it is trying to be an interactive shell. This points people towards > interactively typing in the commands, which is horrific when you get > anywhere near the JSON, or even dot-notation traditional commands. > > If it was just a qmp-client that was single shot, we'd encourage > people to create the JSON in a sensible way - vim/emacs/whatever.
Tooling can help with typing JSON. Mature tooling for editing JSON files exists. I'm not aware of such tooling for interactive use of JSON. It certainly could be made. qmp-shell tries to help by "improving" the JSON syntax, half-heartedly. I doubt that's a good idea. Kubernetes went the "put complex configuration into files, use the mature tooling for editing files" route. I think we can call that a success. The fact that JSON is not meant to serve as configuration file format / command language for human users bears repeating. It's a data interchange format. Kubernetes supplemented JSON (adequate for machines) with YAML (more pleasant for humans, I guess). I'm no friend of YAML myself (too much syntax, not enough types), but once again, I think we can call that a success, at least for Kubernetes. > Bash/dash/zsh/$whatever is their interactive shell, with massively > more features than qmp-shell. You have command history, autocomplete, > conditional and looping constructs, and everything a normal shell > offers. > > The only strong reason for qmp-shell to be interactive would be if > the initial protoocl handshake was too slow. I can't see that being > a problem with QMP. Me neither. The connection overhead may matter for non-interactive uses. These are better off without a middleman. [...]
