"Daniel P. Berrange" <berra...@redhat.com> writes:
> On Thu, Feb 02, 2017 at 08:42:33PM +0100, Markus Armbruster wrote:
>> === Dotted keys ===
>>
>> One sufficiently powerful syntax extension already exists: the dotted
>> key convention. It's syntactically unambiguous only when none of the
>> KEYs involved contains '.' To adopt it across the board, we'd have to
>> outlaw '.' in KEYs. QAPI outlaws '.' already, but we have a bunch of
>> QOM properties names with '.'. We'd have to rename at least the ones
>> that need to be accessible in -object.
>
> We don't neccessarily need to rename - there's a couple of alternatives
>
> - Allow registration of property name aliases, so there's two
> names to access the same property. The old one with the '.'
> in it for back compat, and a new one without the '.'.
Might have other uses, too.
> - Magically remap '.' to '_'. eg if user specifies foo_bar and
> there's no foo_bar present, then also look for foo.bar
I'm wary of such magic, but yes, it's an option.
Rename is the simplest fix when it's possible.
>> Dotted keys can't express member names that look like integers. We'd
>> have to outlaw them at least for the objects that are accessible on the
>> command line. Once again, QAPI outlaws such names already. QOM is
>> anarchy when it comes to names, however.
>>
>> The way dotted keys do arrays is inconsistent with how QOM's automatic
>> arrayification (commit 3396590) do them: foo.0 vs. foo[0]. Backward
>> compatibility makes changing the dotted key convention awkward. Perhaps
>> we can still change QOM.
>
> It is a shame - foo[0] is clearly better as it avoids need to outlaw
> member names that are pure integers.
Yes, but you have to quote foo[0] for the shell, unlike foo.0.
> IIRC, we outlaw members names that begin with a "_", so if we must
> support member names that are integers, we could allow them to be
> given unambigously by using foo._0 to dinstiguish from foo.0
> array access.
QAPI permits leading '_' only for __RFQDN_ downstream extension
prefixes.
Note that even without dotted key convention, you can define QOM names
hostile to command line use: ',' needs be escaped by doubling, shell
meta-characters need to be escaped for the shell, and anything with '='
is impossible to use as KEY.
I stand by my opinion that our failure to define and outlaw anti-social
names consistently is a self-inflicted wound.
>> === Structured values ===
>>
>> The dotted key convention messes with KEY syntax to permit structured
>> values. Works, but the more conventional way to support structured
>> values is a syntax for structured values.
>>
>> An obvious one is to use { KEY=VALUE, ...} for objects, and [ VALUE,
>> ... ] for arrays. Looks like this:
>>
>> -drive 'driver=quorum,
>> child=[{ driver=file, filename=disk1.img },
>> { driver=host_device, filename=/dev/sdb },
>> { driver=nbd, host=localhost } ]'
>>
>> Again, lines broken and indented for legibility; you need to join them
>> for actual use.
>>
>> There's a syntactic catch, though: a value of the form [ ... ] can
>> either be an array or a string. Which one it is depends on the type of
>> the key. To parse this syntax, you need to know the types, unlike JSON
>> or traditional QemuOpts. Unless we outlaw strings starting with '{' or
>> '[', which feels impractical.
>>
>> But wait, there's another syntactic catch: in traditional QemuOpts, a
>> value ends at the next unescaped ',' or '\0'. Inside an object, it now
>> also ends at the next unescaped '}', and inside an array, at the next
>> unescaped ']'. Or perhaps at the next space (the example above assumes
>> it does). That means we either have to provide a way to escape '}', ']'
>> and space, or find another way to delimit string values, say require '"'
>> around strings whenever the string contains "funny" characters.
>>
>> So, if escaped ',' wasn't ugly and confusing enough for you...
>
> I'm not a fan of this because it essentially introduces yet another
> syntax, different from everything that exists today.
>
>> === 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?
>
> I think the JSON approach is fine, *iff*, QEMU is being managed by
> a machine (ie libvirt). If QEMU is being managed by a human, then
> typing & quoting json in the CLI is pretty horrible - when I write
> json I pretty much always get the syntax wrong several times, with
> the trailing comma rules being particularly tedious. IMHO this is
> why humans tend to still use the HMP (or the HMP-lookalike QMP-shell
> to talk to QMP), rather ever using QMP directly.
Getting humans to use QMP for interactive work is a non-goal.
> The block layer allows both dotted keys and JSON already IIUC.
>
> As such I'm inclined to say we should support dotted syntax as the
> primary human facing syntax and JSON as the machine targetted
> syntax. Essentially just do what the block layer already does
> and avoid inventing something new. It might not be perfectly
> to our taste if we had a green-field, but given historical
> baggage, I think its basically fine.
Thanks!
