[Libguestfs] [PATCH RFC 1/5] qapi: Enable enum member introspection to show more than name
pkrempa at redhat.com
Fri Sep 17 14:49:33 UTC 2021
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
> 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:
> 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.
More information about the Libguestfs