Fam Zheng <f...@redhat.com> writes:
> On Sat, 02/04 14:35, Markus Armbruster wrote:
>> Fam Zheng <f...@redhat.com> 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,children=@children0
>> > \
>> > -drive if=virtio,id=primary-disk0,driver=qcow2,file=@quorum0
>> >
>> > 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
>>
>> KEY=@REF 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 KEY@=REF?
Requires outlawing KEYs ending with '@'. QAPI outlaws such names
already. QOM doesn't, but I figure no such names exist so far.
