On Fri, Feb 07, 2025 at 01:31:47PM +0100, Markus Armbruster wrote: > Akihiko Odaki <akihiko.od...@daynix.com> writes: > > [...] > > > Let me go back to the discussion of the bool/OnOffAuto problem below: > > > > The values the command line syntax accepts are on/yes/true/y and > > off/no/false/n. > > > > For the command line syntax, you can always use on/off whether the type is > > bool or OnOffAuto. In my opinion, it is still not good to reject yes/true/y > > and no/false/n for OnOffAuto; why do we suddenly reject them when the > > property gets the "auto" value? As you pointed out, the usage of enum is > > our internal concern and should not bother users. > > The command line is a different mess. > > For better or worse (worse if you ask me), we added code to accept > additional syntax for bool values. > > Doing the same for enums that happen to have some values that look > boolean at a glance is in my opinion a terrible idea. We have at least > two: OnOffAuto and OnOffSplit. > > But let's get back to QMP.
Before we get back to QMP I should point out that our current HMP bool / OnOffAuto properties are a significant developer foot-gun in terms of back compat. Though I'm struggling to find the examples, I'm pretty sure I've seen patches where we converted a property from bool to OnOffAuto, with the developer (likely) thinking it was back-compatible. It does have the illusion of being compatible given that the HMP bool syntax is accepting 'on/off' (especially when our usage examples often on/off rather than yes/no/true/false) values ... very much not the case for QMP though. This does make me really want the idea of an "alternate" in QMP that can be made to work for scalars. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
