[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V2 1/4] qapi: strList_from_string
From: |
Markus Armbruster |
Subject: |
Re: [PATCH V2 1/4] qapi: strList_from_string |
Date: |
Mon, 19 Jun 2023 07:52:02 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Steven Sistare <steven.sistare@oracle.com> writes:
> On 6/13/2023 8:33 AM, Markus Armbruster wrote:
>> Steven Sistare <steven.sistare@oracle.com> writes:
[...]
>>> What design principle does strList_from_string contradict? Are you OK with
>>> putting the simplified version shown above in qapi-util?
>>
>> The design principle is "use JSON to encode structured data as text in
>> QAPI/QMP".
>>
>> Do: "mumble": [1, 2, 3]
>>
>> Don't: "mumble": "1,2,3"
>
> I don't mumble, but I sometimes mutter and ramble.
Hah!
>> We violate the principle in a couple of places. Some are arguably
>> mistakes, some are pragmatic exceptions.
>>
>> The principle implies "the only parser QAPI needs is the JSON parser".
>>
>> By adding other parsers to QAPI, we send a misleading signal, namely
>> that encoding structured data in a way that requires parsing is okay.
>> It's not, generally.
>>
>> So, I'd prefer to find another home for code that splits strings at
>> comma / delimiter.
>>
>>> (and apologies for my long delay in continuing this conversation).
>>
>> I'm in no position to take offense there ;)
>
> Thanks, that makes it clear.
>
> I propose to move strList_from_string and strv_from_strList to new files
> util/strList.c and include/qemu/strList.h, and leave QAPI_LIST_LENGTH in
> include/qapi/util.h.
>
> (cutil.c already has string functions, but only uses simple C types, so
> not the best place to add the strList type).
>
> Sound OK?
Works for me. Thanks!