Re: [PATCH RFC 0/1] QOM type names and QAPI

[Markus Armbruster <armbru@redhat.com>]

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Fri, Jan 29, 2021 at 02:25:56PM +0100, Paolo Bonzini wrote:
>> On 29/01/21 13:17, Daniel P. Berrangé wrote:
>> > > On this one, my vote would be "no". "Versioned machine names
>> > > include the QEMU version number" is pretty well entrenched,
>> > > and requiring users to remember that when they want version 4.2
>> > > they need to remember some other way of writing it than "4.2"
>> > > seems rather unfriendly. And 550 uses of '.' is a lot.
>> > We can't make  keyval_parse() accept "/" instead of ".", but can
>> > we make it accept "/" in addition to ".", and then encourage "/"  ?
>> > 
>> > People simply wouldnt be able to use "." as keyval separator if
>> > they're using typenames containing "." (or would have to escape
>> > the typename.
>> 
>> '.' is much more common than '/', and is shared by about all programming
>> languages that have JSON-ish data structures natively.  So using '/' seems
>> decidedly worse to me.
>
> Worse than what, exactly?
>
> Accepting "/" when "." is ambiguous seems decidedly better than
> the following alternatives:
> - renaming machine types to names like "q35-5-0"; or
> - having to escape "." in the command line.

Yes.

However, the ambiguity arises only when type names occur as key, as I
noted in my followup Message-ID: <875z3g2c1f.fsf@dusky.pond.sub.org>.

I figure we could relax the QAPI enum naming rules to permit '.', with
drawbacks that feel tolerable.  One of them: if we ever manage to put
QAPI enums in a key position, we're screwed :)