[Top][All Lists]

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

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

From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax
Date: Sat, 04 Feb 2017 14:35:19 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Fam Zheng <address@hidden> writes:

> On Thu, 02/02 20:42, Markus Armbruster wrote:
>> === 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 :)
>> Opinions?  Other ideas?
> Here's my poor attempt:
> The dotted syntax, as the simpler of two, can cover everyday use very well.  
> If
> we introduce an "@reference" extension to it which can help the expresiveness,
> we can have a hybrid solution. It's not the cleanest interface and syntax, but
> escaping, nesting and quoting can all be divide-and-conqured in their optimal 
> way.
> What I'm imagining is something like:
>     -json "id=children0,text=[
>                 { 'driver': 'null-co://' },
>                 { 'driver': 'null-co://' },
>                 { 'driver': 'null-co://' }
>             ]" \
>     -dot \
> id=quorum0,driver=quorum,read-pattern=fifo,vote-threshold=1,address@hidden \
>     -drive if=virtio,id=primary-disk0,driver=qcow2,address@hidden
> IOW "-json" and "-dot" define options that is intended to be referenced from
> other dotted keys (quorum0 uses children0, and in turn primary-disk0 uses
> quorum0).
> Note: "-dot" here could be replaced with a -blockdev in this specific case but
> I'm demostrating it just in case it is useful generically.
> Fam

address@hidden for references creates the same issue as KEY=[VALUE,...] for
arrays: you need to know the type of KEY to decide whether @REF is a
reference or a string, unless we outlaw strings starting with '@'.

Not a show-stopper, but it does preclude a design where a simple parser
feeds into a type-aware visitor, which is how the JSON -> QObject ->
QAPI pipeline works.

If you get creative in the VALUE part, you complicate the parser and/or
need to add quoting.

If you get creative in the KEY part, you need to restrict valid names.

reply via email to

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