On 05/13/2013 07:18 AM, Luiz Capitulino wrote:
>>>> Luiz, any idea how to do something like this, a QAPI enum with values
>>>> that are determined at runtime? Especially with respect to the coming
>>>> schema introspection?
>>>
>>> Or maybe we make the 'enum' list ALL possible types, but then add a
>>> query-* command that returns an array of only those enum values that are
>>> supported.  Introspection would see all types, but the query command
>>> would be the useful variant that is runtime-dependent.
> 
> Agreed. This is a capability, and we're adding query- commands to query
> capabilities.
> 
>> Then is there any advantage in making it an enum in the first place?
> 
> Eric is in a better position to answer this, but the fact that this can
> be queried isn't a strong pro for having it?

Hmm, you raise an interesting point - if we have a query-block-formats
command that returns an array of strings, then keep 'str' everywhere
else a format is required, that is no different for what is sent over
the wire compared to a query-block-formats that returns an array of
'BlockFormat' enum values, with the enum showing all possible formats
(even if support wasn't compiled in), and with 'BlockFormat' everywhere
else.  Introspection-wise, you'd have to know that you call
query-block-formats instead of introspecting on the type of the format
argument, but information-wise, there's no loss of details if the query-
command provides the runtime list, and the remaining commands stick with
'str'.  I still think an enum is a bit nicer from the type-safety
aspect, but I'm finding it hard to envision any scenario where libvirt
would have to resort to introspection if we have a query-block-formats
in place, and thus am not opposed to your idea of avoiding the enum.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org