[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.
- Re: [Qemu-block] Non-flat command line option argument syntax, (continued)
- Re: [Qemu-block] Non-flat command line option argument syntax, Peter Krempa, 2017/02/03
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Richard W.M. Jones, 2017/02/03
- Re: [Qemu-block] Non-flat command line option argument syntax, Max Reitz, 2017/02/03
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Fam Zheng, 2017/02/04
- Re: [Qemu-block] [Qemu-devel] Non-flat command line option argument syntax, Daniel P. Berrange, 2017/02/06
- Re: [Qemu-block] Non-flat command line option argument syntax, Markus Armbruster, 2017/02/06
- Re: [Qemu-block] Non-flat command line option argument syntax, Kevin Wolf, 2017/02/06