Re: [Libguestfs] [PATCH RFC 1/5] qapi: Enable enum member introspection to show more than name
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/24f1709cfae72cd765d02dc2124d6...
https://gitlab.com/pipo.sk/libvirt/-/commit/5909db9d4994327b3f64d5c329edd...
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.