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.
