Re: [Qemu-block] Non-flat command line option argument syntax

[Eric Blake]

On 02/02/2017 01:42 PM, Markus Armbruster wrote:

> 
> === Structured values ===
> 
> The dotted key convention messes with KEY syntax to permit structured
> values.  Works, but the more conventional way to support structured
> values is a syntax for structured values.  
> 
> An obvious one is to use { KEY=VALUE, ...} for objects, and [ VALUE,
> ... ] for arrays.  Looks like this:
> 
>     -drive 'driver=quorum,
>             child=[{ driver=file, filename=disk1.img },
>                    { driver=host_device, filename=/dev/sdb },
>                    { driver=nbd, host=localhost } ]'
> 
> Again, lines broken and indented for legibility; you need to join them
> for actual use.
> 
> There's a syntactic catch, though: a value of the form [ ... ] can
> either be an array or a string.  Which one it is depends on the type of
> the key.  To parse this syntax, you need to know the types, unlike JSON
> or traditional QemuOpts.  Unless we outlaw strings starting with '{' or
> '[', which feels impractical.

Another syntactic catch: from the shell,

-drive driver=quorum,child=[...]

is insufficiently quoted, and MIGHT glob to a completely different
argument (or even multiple arguments) depending on the (oddly-named)
contents of the current directory.  Any use of [] HAS to consistently
recommend use with shell quotes.  Using straight JSON already has to use
shell quotes (generally '' for the overall argument, and "" for key
names and string values within the JSON, although our parser as an
extension supports '' for key names and string values which pairs with
"" for the overall argument and allows the use of $var shell interpolation).

> 
> === Comparison ===
> 
> In my opinion, dotted keys are weird and ugly, but at least they don't
> add to the quoting mess.  Structured values look better, except when
> they do add to the quoting mess.
> 
> I'm having a hard time deciding which one I like less :)

Both are a bit awkward.  I think dotted keys require more typing but
less shell quoting than structured values.  And with either approach, it
would STILL be nice if we taught QemuOpts to strip whitespace after
delimiting commas - the only requirement is that no key value can start
with space, which QAPI enforces, and QOM is unlikely to break, although
the benefits of stripping whitespace are only apparent when you remember
to use shell quoting over the entire argument (which partially defeats
the purpose of trying to come up with a syntax that needs less shell
quoting).

> 
> Opinions?  Other ideas?

I don't think command line length is a problem; most command lines are
generated. I'm torn on whether a simplified structured values is nicer
than full-blown JSON; your argument about having the same JSON work on
both the command line and through QMP resulting in less work for
management apps is interesting.  And reusing an existing syntax instead
of inventing yet another one always has the benefit of less code to
maintain.  So even though it's harder to type by hand, I'm somewhat
leaning towards full JSON (where a leading '{' says to parse using JSON
until the closing '}'), rather than any other structured value
representation.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature