qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making QEMU easier for management tools and applications


From: Kevin Wolf
Subject: Re: Making QEMU easier for management tools and applications
Date: Sun, 2 Feb 2020 10:21:52 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

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}}
> 
> With shells like bash, that would need quoting to avoid unintended brace
> expansions.  It is not the end of the world to require shell quoting (and
> passing JSON on the command line definitely needs it), but a syntax that
> avoids shell quoting is marginally easier to type and reason about.

My point was that even with such a simplified syntax (ignoring all the
implication of using it on the command line), the additional nesting
that simple unions give you would still be bad.

That said, 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.

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]