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

[Fam Zheng]

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

Fam