"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * 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
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.
