Re: qmp-shell for GSoC/Outreachy?

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) 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

Yes, good point.

>   b) Lack of room for comments

An interactive REPL can do without comments, but for scripting and for
configuration files, they're essential.

>> 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.

I'm afraid such a requirement would first complicate things massively,
and then we'd accidentally mess up details anyway.

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

QMP is working in its intended role "for use by machines".  JSON's
laughably weak specification of numbers is an issue, but it hardly
justifies starting over.

We're looking for a qmp-shell syntax that's more pleasant to use for
humans.