Steven Sistare <steven.sist...@oracle.com> writes:

> On 4/9/2025 10:44 AM, Markus Armbruster wrote:
>> Steven Sistare <steven.sist...@oracle.com> writes:
>> 
>>> On 4/9/2025 9:34 AM, Markus Armbruster wrote:
>>>> Steven Sistare <steven.sist...@oracle.com> writes:
>>>>> On 4/9/2025 3:39 AM, Markus Armbruster wrote:

[...]

>>>> Anyway, asking you to fix design mistakes all over the place wouldn't be
>>>> fair.  So I'm asking you something else instead: do you actually need
>>>> the error information?
>>>
>>> I don't need the specific error message.
>>>
>>> I could return a boolean meaning "property not available" instead of 
>>> returning
>>> the exact error message, as long as folks are OK with the output of the 
>>> qom-tree
>>> script changing for these properties.
>> 
>> Let's put aside the qom-tree script for a moment.

[...]

>> Back to qom-tree.  I believe this script is a development aid that
>> exists because qom-get is painful to use for humans.  Your qom-tree
>> command would completely obsolete it.  I wouldn't worry about it.
>> If you think I'm wrong there, please speak up!
>
> Regarding dropping the error messages, I agree, I was just pointing it out
> in case anyone objected.

Appreciated.

> Yes, the new command plus a formatter like jq obsoletes the qom-tree script.
> Just to be clear, I do not propose to delete the script, since folks are
> accustomed to it being available, and are accustomed to its output.  It also
> serves as a nice example for how to use the new command.

I have little use for scripts/qmp/ myself.  Since nothing there adds to
my maintenance load appreciably, I don't mind keeping the scripts.
qom-fuse is rather cute.

> Do you want to review any code and specification now, or wait for me to send
> V2 that deletes the error member?  The changes will be minor.

v1 should do for review.  Thanks!

Reply via email to