Markus Armbruster <arm...@redhat.com> writes: > Kevin Wolf <kw...@redhat.com> writes: > >> Am 05.02.2020 um 11:03 hat Markus Armbruster geschrieben: >>> Kevin Wolf <kw...@redhat.com> writes: [...] >>> > Adding a key gets more complicated with your proposed interface because >>> > state must be set explicitly now whereas before it was derived >>> > automatically from the fact that if you give a key, only active makes >>> > sense. >>> >>> The explicitness could be viewed as an improvement :) >> >> Not really. I mean, I really know to appreciate the advantages of >> -blockdev where needed, but usually I don't want to type all that stuff >> for the most common tasks. qemu-img amend is similar. >> >> For deleting, I might actually agree that explicitness is an >> improvement, but for creating it's just unnecessary verbosity. >> >>> If you'd prefer implicit here: Max has patches for making union tags >>> optional with a default. They'd let you default active to true. >> >> I guess this would improve the usability in this case.
Thinking and writing in the "Making QEMU easier for management tools and applications" monster thread have made me realize we're mixing up two aspects that ought to be kept separate: machine-friendly QMP and human-friendly CLI. You argue that $ qemu-img amend -o encrypt.keys.0.new-secret=sec0 test.qcow2 is nicer than $ qemu-img amend -o encrypt.keys.0.state=active,encrypt.keys.0.secret=sec0 test.qcow2 and you do have a point: humans want their CLI terse. Redundancy is unwanted, except perhaps to protect users from dangerous accidents. In this example, state=active is redundant when a secret is given, because anything else would be an error. In QMP, however, we like things simple and explicit, and we eschew magic. This particular magic might just be simple enough to be acceptable in QMP. We'd "merely" have to support explicit defaults in the schema (a clear improvement if you ask me), and optional union tags (tolerable as long as the default comes from the schema, I guess). My point is: QAPI schema design *must* focus on QMP and nothing else. If we try to serve both QMP and human-friendly CLI, we'll likely botch both. I believe a truly human-friendly CLI requires more than just human-friendly concrete syntax for QMP. Same as HMP, really.