Paolo Bonzini <pbonz...@redhat.com> writes: > Il dom 2 feb 2020, 10:22 Kevin Wolf <kw...@redhat.com> ha scritto: > >> Am 31.01.2020 um 13:27 hat Eric Blake geschrieben: >> > On 1/28/20 6:54 AM, Kevin Wolf wrote: >> > >> > > > >> > > > The arguments as dotted keys: >> > > > >> > > > id=bar,backend.type=file,backend.data.out=/tmp/bar.log >> > > > >> > > > Observe there's quite some of nesting. While that's somewhat >> cumbersome >> > > > in JSON, it's a lot worse with dotted keys, because there nesting >> means >> > > > repeated key prefixes. I could give much worse examples, actually. >> > > >> > > This is true, but even without the repeated keys (e.g. in a syntax that >> > > would use brackets), it would still be unnecessarily verbose and >> > > probably hard to remember: >> > > >> > > id=bar,backend={type=file,data={out=/tmp/bar.log}} >> >> [...] I actually think that a syntax like this might make sense for >> something like qmp-shell. It might even be more convenient on the >> command line than dotted keys if you get a lot of repetition (despite >> the required quoting), but it's strictly speaking incompatible because >> you could use {} in strings today. >> > > If you are willing to feed schema info to the parser, in principle you > could keep backwards compatibility. There would be limitations such as > putting the discriminator before the fields, so I am not sure it's a good > idea.
Problem: the 'any' type, where the schema doesn't provide the necessary information. Problem: 'gen': false, where we pass the arguments raw, ignoring the schema. If we didn't restrict alternate types so severly, it would also be a problem. For instance, with { 'alternate': 'Alt', 'data': { 'one': 'number', 'two': 'str' } } we don't know what to do for value "on" branch to take for value 42. Not a problem because we reject this alternate. See tests/qapi-schema/alternate-conflict-*json for more examples. > Better QOM introspection would be a requirement, too. I guess this is what you believe is needed to solve these problems.