[Qemu-devel] QMP's success response

[Qemu-devel] QMP's success response

[Luiz Capitulino]

 Hi there,

 Currently, when a regular command doesn't have any data to output,
QMP will emit:

{ "return": "OK" }

 I thought this was a good idea because it has a clear meaning. Silly me,
this is optimized for humans, but for machines it introduces the problem
that such commands can't be changed to return values.

 I'm not sure this is will ever happen, but to stay safe a better way
would be to return an empty dict, like this:

{ "return": {} }

 Which can be read as 'command succeeded, but didn't return any data'.

 As the release is not done yet we still can change it, is anyone against?

[Qemu-devel] Re: QMP's success response

[Daniel P. Berrange]

On Thu, Dec 17, 2009 at 03:41:47PM -0200, Luiz Capitulino wrote:
> 
>  Hi there,
> 
>  Currently, when a regular command doesn't have any data to output,
> QMP will emit:
> 
> { "return": "OK" }
> 
>  I thought this was a good idea because it has a clear meaning. Silly me,
> this is optimized for humans, but for machines it introduces the problem
> that such commands can't be changed to return values.
> 
>  I'm not sure this is will ever happen, but to stay safe a better way
> would be to return an empty dict, like this:
> 
> { "return": {} }
> 
>  Which can be read as 'command succeeded, but didn't return any data'.
> 
>  As the release is not done yet we still can change it, is anyone against?

That's fine by me. libvirt merely checks for whether 'error' vs 'return'
exist when first deciding whether it has been successful. We only look at 
the contents of the 'return' key for commands expecting actual data back.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] QMP's success response

[Markus Armbruster]

Luiz Capitulino <lcapitulino@redhat.com> writes:

>  Hi there,
>
>  Currently, when a regular command doesn't have any data to output,
> QMP will emit:
>
> { "return": "OK" }
>
>  I thought this was a good idea because it has a clear meaning. Silly me,
> this is optimized for humans, but for machines it introduces the problem
> that such commands can't be changed to return values.
>
>  I'm not sure this is will ever happen, but to stay safe a better way
> would be to return an empty dict, like this:
>
> { "return": {} }
>
>  Which can be read as 'command succeeded, but didn't return any data'.
>
>  As the release is not done yet we still can change it, is anyone against?

I'm very much in favor of it.

Re: [Qemu-devel] QMP's success response

[Jamie Lokier]

Luiz Capitulino wrote:
> 
>  Hi there,
> 
>  Currently, when a regular command doesn't have any data to output,
> QMP will emit:
> 
> { "return": "OK" }
> 
>  I thought this was a good idea because it has a clear meaning. Silly me,
> this is optimized for humans, but for machines it introduces the problem
> that such commands can't be changed to return values.
> 
>  I'm not sure this is will ever happen, but to stay safe a better way
> would be to return an empty dict, like this:
> 
> { "return": {} }

Logically, it would be { "return": null }.  What if future return
value is actually an empty dict? ;-)  E.g. from an enumeration command,
where the enumerated set is empty.

-- Jamie

Re: [Qemu-devel] QMP's success response

[Luiz Capitulino]

On Thu, 17 Dec 2009 19:09:18 +0000
Jamie Lokier <jamie@shareable.org> wrote:

> Luiz Capitulino wrote:
> > 
> >  Hi there,
> > 
> >  Currently, when a regular command doesn't have any data to output,
> > QMP will emit:
> > 
> > { "return": "OK" }
> > 
> >  I thought this was a good idea because it has a clear meaning. Silly me,
> > this is optimized for humans, but for machines it introduces the problem
> > that such commands can't be changed to return values.
> > 
> >  I'm not sure this is will ever happen, but to stay safe a better way
> > would be to return an empty dict, like this:
> > 
> > { "return": {} }
> 
> Logically, it would be { "return": null }. 

 In practice it brings the same problem.

> What if future return value is actually an empty dict? ;-)

 This is compatible and has the same end result.

>  E.g. from an enumeration command,  where the enumerated set is empty.

 Either, the command could return the empty dict or a dict
containing a "enum" key, which would be emitted like:

{ "result": { "enum": {} } }