On 09/25/2014 02:06 AM, Markus Armbruster wrote:

>>
>> The QAPI schema's 'returns' becomes "return" on the wire.  We suck.
>>
>> qmp-spec.txt is *wrong*!  We actually use json-array in addition to
>> json-object.
> 
> Actually, we use json-int and json-str as well:
> query-migrate-cache-size, ringbuf-read, human-monitor-command.
> 
>> Similar argument on types wanted as for 'data' / "arguments" above.  I
>> think we should permit exactly the same QAPI types, plus lists.
> 
> The similarity to 'data' just isn't there.  Separate analysis needed.

Correct.  'data' and 'returns' are different beasts when it comes to
acceptable types.  And different still from the acceptable type of each
member of a dictionary.  But my check_type function in 13/19 is flexible
enough to cover all the cases.

> 
> Any QAPI types that don't make sense, other than list with length != 1?

Return of an anon union isn't used yet, but _might_ make sense (as the
only feasible way of changing existing commands that return an array or
primitive extensible to instead return a dict) - except that back-compat
demands that we can't return a dict in place of a primitive unless the
arguments of the command are also enhanced (that is, older callers are
not expecting a dict, so we can't return a dict unless the caller
witnesses they are new enough by explicitly asking for a dict return).

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