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!