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

[Markus Armbruster]

Fam Zheng <address@hidden> writes:

> On Sat, 02/04 14:35, Markus Armbruster wrote:
>> 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.
>
> How about address@hidden

Requires outlawing KEYs ending with '@'.  QAPI outlaws such names
already.  QOM doesn't, but I figure no such names exist so far.