* Markus Armbruster (arm...@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 / dgilb...@redhat.com / Manchester, UK
