Re: qmp-shell for GSoC/Outreachy?

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
  That I wrote:
> >
> > I believe it should be a python shell with added commands.
> >
> > Simple things should be simple.
> >   e.g. adding a disk from a local file should be trivial.
> >
> > Complex things can be complex - but it would be better if they were
> > simple.
> >
> >   It's OK if the worst case of a blockdev is a bit hairy, but
> >   watch out for cases where the hairyness creeps in unnecessarily.
> 
> Designing interfaces to complex machinery is hard.  Experience tells
> that we do okay when we focus on the building blocks first.  That's
> -blockdev.  When we start with trying to make simple things simple, we
> end in swamps.  That's -drive.
> 
> Focus on building blocks is of course no excuse for unnecessary
> hairiness.
> 
> It's also no reason not to build more convenient things on top of the
> building blocks.  I doubt they should go into QMP, though.

I see where you're coming from, but I like -drive - it's simple for
simple things; maybe it's a nightmare for some others, but if I just
want a VM with a disk on virtio, it's easy.

But I agree if you have good building blocks and they're easy to
understand and easy to represent, it's not a bad start.

> > If the user screwsup, it should give an error that prompts the user
> > to the parameter they got wrong.
> >
> > Output from commands should normally be pretty formatted (with an option
> > to display raw json for those needing it).
> >   e.g. that 'query-version' should give either just the package
> >   version (as info version currently does) or:
> >       4.2.50  Package: v4.2.0-1188-gd95a3885a9
> >
> > We shouldn't lose any HMP commands that some people find useful
> >   Ditching HMP isn't an option until we've got almost all of it
> >   covered.
> 
> In particular, we currently use HMP for debugging and monitoring
> purposes, where we don't need or want QMP's rigor, neither its rigorous
> interface stability, nor its structured I/O.  We want the "whipuptitude"
> we get from monitor_printf().  This is actually a point David has made
> several times.
> 
> To have a qmp-shell replace HMP, I think it needs to be able to
> 
> * Go beyond 1:1
> 
>   We tried a 1:1 mapping between HMP and QMP commands, and it didn't
>   work out.  HMP's replacement should let us build convenient commands
>   from QMP building blocks.
> 
>   We tried a 1:1 mapping between HMP and QMP command arguments, guided
>   by @args_type.  Worked out for simple cases, but was too constricting.

Yes, it works for some things.

> * Preserve "whipuptitude" [David]
> 
>   I figure that means allowing some in QMP.  Without compromising its
>   core mission, of course.
> 
> * As discoverable as HMP is now [Kevin]
> 
> * Help, completion and such at least on par with what HMP provides now
> 
> Highly desirable:
> 
> * Support transitioning to the machine interface [John]
> 
>   Let humans start playing with the human interface, and when they feel
>   the need to automate, help them transition to QMP.
> 
> Back to John's question on qmp-shell syntax, which hasn't been answered
> so far.
> 
> JSON is a data-interchange format.  It doesn't try to be a configuration
> format or programming language syntax for human use.  It gets pressed
> into these roles with entirely predictable poor results.
> 
> Pain points of JSON include having to count parenthesises and having to
> quote so bloody much.  Additional QMP pain points include long names and
> excessive nesting.

Some other pet hates:
  a) Number formats are awful for our uses
  b) Lack of room for comments

> For the configuration format role, more usable alternatives exist.  YAML
> is a popular one.
> 
> qmp-shell is a REPL.  It needs a REPL-friendly syntax.  I doubt YAML is
> or even tries to be REPL-friendly.  I'd love to be wrong; the first rule
> of language design is "don't".
> 
> Other language suggestions?

While I hate XML, there's a certain niceness in using the same thing as
libvirt for places that mean the same thing; but that would have the bad
requirement that things meant *exactly* the same thing.

But, for machine representations, I'm not sure moving away from JSON is
a requirement.

Dave

> On making JSON suck less in this role:
> 
> LISP REPLs demonstrate that computers can assist effectively with
> counting parenthesises, and with completing long names.
> 
> We could make quoting optional for sufficiently nice object member
> names.  QAPI naming rules ensure niceness, actually.
> 
> We could make quoting optional for certain string literals.  Simple
> enough for literals that can only be a string, like abc.  For literals
> that could be something else like 123 or true, omitting quotes creates
> ambiguity.  When the schema accepts only one of the possible types, the
> ambiguity goes away.  Complexity stays, however.
> 
> Excessive nesting should ideally be attacked in QMP itself, but backward
> compatibility makes that hard.
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK