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

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 27.02.2017 um 11:27 hat Markus Armbruster geschrieben:
>> Markus Armbruster <armbru@redhat.com> writes:
>> 
>> [...]
>> > === 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.
>> >
>> > 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.
>> 
>> Design flaw: there is no good way to denote an empty array or object
>> other than the root object.
>> 
>> Empty KEY=VALUE,... is valid and results in an empty root object.
>> 
>> Presence of a KEY that contains periods results in additional non-root
>> objects or arrays.  For instance, KEY a.b.c results in root object
>> member "a" that has member "b" that has (scalar) member "c".
>> 
>> These additional objects and arrays all have at least one member, by
>> construction.
>> 
>> Begs the question how to denote an empty object or array other than the
>> root.
>> 
>> A natural idea is to interpret "absent in KEY=VALUE,..." as empty.
>> After all, removing one key from it removes one member when there are
>> more, so why not when there aren't.
>> 
>> Sadly, it doesn't work: "absent in KEY=VALUE,..." already means
>> "optional object/array absent", which isn't the same as "empty
>> object/array present".
>> 
>> Without additional syntax, all we can do is choose what exactly to make
>> impossible:
>> 
>> * Absent key means absent, period.  No way to do empty array or object.
>>   This is what I implemented.
>
> I'm not currently aware of any places where the difference between a
> present, but empty array and an absent array is actually significant, so
> this is probably the most consistent and useful way to interpret things.
>
> In other words, I agree with your implementation.
>
>> * Absent key means absent, except when the member is visited it means
>>   empty.  No way to do absent optional array or object.
>> 
>> * Likewise, but if the visit is preceeded by a test for presence with
>>   visit_optional(), it means absent again.  No way to do present
>>   optional empty array or object.  This requires keeping additional
>>   state.
>> 
>> Any bright ideas on how to avoid making things impossible?
>
> I can't see any other option than extending the syntax if we need this.
> We can't tell the difference between a string and any other object
> description after =, so we would need to make use of reserved characters
> in the key name.

Think so, too.

>                  Maybe just 'foo.array[]' (without any =) for an empty
> array or something like that.

Yes, that should do.  Likewise foo.object{} for empty object.

{} doesn't even need quoting.  [] may.

A trailing period without '=' makes some sense, but looks a bit
error-prone, and can't distinguish between array and object.

> Before we introduce anything like this, do we actually need it?

I don't know whether anything needs optional, present and empty.  But
even if the answer is "no" today, it need not remain "no".

Anyone running into a case of "yes", will have to fall back to the JSON
form of -blockdev.  Strengthens my belief that providing JSON there is a
good idea.

The insufficient generality of dotted keys bugs me a bit.  Not sure
whether it justifies more syntax now.  But we should document it.