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
signature.asc
Description: OpenPGP digital signature
