On 04/01/2015 01:54 AM, Paolo Bonzini wrote:
>
>
> On 31/03/2015 19:03, Eric Blake wrote:
>>>>
>>>> Apart from this, looks good.
>> Changing a "return":{} to "return":0 is not backwards-compatible.
>
> Why not?It's only a minor incompatibility, but a client that hard-codes itself to parsing "returns":0 (that is, expecting a json-number) will fail when talking to an older qemu that provided a json-object instead; while a client that expects a json-object always and can search for a "key":0 integer pair within that object that may or may not be present (we already document that clients MUST be prepared for dictionary members to be optional, but do NOT advise that clients must be prepared for a change between fundamental JSON types). Yes, the backwards-incompatibility is a weak argument, but as my pending series will be requiring all new commands to whitelist a non-dict return, we might as well avoid making this another case for that whitelist. My stronger argument in my other email is that returning a single integer is not much information. Since we have FULL statistics (how much did each file system trim), why not return it all, for the end user to take advantage of if desired? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
