On Wed, Sep 15, 2021 at 21:24:21 +0200, Markus Armbruster wrote: > The next commit will add feature flags to enum members. There's a > problem, though: query-qmp-schema shows an enum type's members as an > array of member names (SchemaInfoEnum member @values). If it showed > an array of objects with a name member, we could simply add more > members to these objects. Since it's just strings, we can't. > > I can see three ways to correct this design mistake: > > 1. Do it the way we should have done it, plus compatibility goo. > > We want a ['SchemaInfoEnumMember'] member in SchemaInfoEnum. Since > changing @values would be a compatibility break, add a new member > @members instead. > > @values is now redundant. We should be able to get rid of it > eventually. > > In my testing, output of qemu-system-x86_64's query-qmp-schema > grows by 11% (18.5KiB).
I prefer this one. While the schema output grows, nobody is really reading it manually. The implementation in libvirt is very straightforward: https://gitlab.com/pipo.sk/libvirt/-/commit/24f1709cfae72cd765d02dc2124d6c954554ea55 https://gitlab.com/pipo.sk/libvirt/-/commit/5909db9d4994327b3f64d5c329edd4b175495bfe > 2. Like 1, but omit "boring" elements of @member, and empty @member. > > @values does not become redundant. Output of query-qmp-schema > grows only as we make enum members non-boring. This has 2 drawbacks: - we would never get rid of either of those - clients would have to check both, one for whether the member is present and second whether it's non-boring. IMO it's simpler for clients just to prefer the new approach when present as the old is simply a subset. > 3. Versioned query-qmp-schema. > > query-qmp-schema provides either @values or @members. The QMP > client can select which version it wants. At least for libvirt this poses a chicken & egg problem. We'd have to query the schema to see that it has the switch to do the selection and then probe with the modern one.
