On 04/24/2013 03:29 PM, Luiz Capitulino wrote:
>> -> { "execute": "query-command-capabilities" }
>> <- { [ { "type": "drive-mirror",
>> "data": [ "granularity", "buf-size" ] },
>> { "type", ... }
>> ] }
>>
>> And whether a '*command' argument should be optional for filtered
>> output, vs. always unconditionally dumping all information on all
>> commands with capabilities, vs. mandatory (can only get capabilities for
>> one command at a time), all goes back to the larger question of whether
>> query-* commands should allow filtering.
>
> Not discussing filtering for now, but your proposal would superseded by
> full introspection, wouldn't it?
Yeah, the two do seem rather similar, in that they are both providing a
form of introspection. As I see it, it boils down to WHAT is being
introspected:
With query-command-capabilities, we are asking about capabilities, which
can always be represented as pure enum values (either the capability is
present or it is not). For DriveMirrorCapabilities we happened to map
two enum values to the name of two optional drive-mirror parameters; but
where we could introduce other capabilities that are unrelated to an
optional parameter; also, we aren't polluting the output with parameters
that don't really reflect capability additions, so even if we don't
provide filtering, the output of a query-command-capabilities will be
relatively small compared to the number of total QMP commands.
With full-blown command introspection, we would want to be asking for a
JSON representation more details about each parameter, in a struct that
looks something like { 'name':'str', 'type':'<enumOfTypes>',
'optional':'boolean', '*default':'<typesafe way of representing the
default of any boolean option>', '*documentation':'str' }. If we don't
provide filtering, then this JSON output might be quite large, because
it covers all QMP commands,
>
> Anyways, I also agree it's a good idea to defer this to 1.6 so we can
> revisit this topic later.
That relieves some pressure :)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
