Tooling to help humans use JSON (was: Making QEMU easier for management tools and applications)

[Markus Armbruster]

Daniel P. Berrangé <address@hidden> 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.

[...]