[Qemu-devel] [RFC 0/5] Monitor handlers convertion to QObject

[Luiz Capitulino <lcapitulino@redhat.com>]

Hi There,

 This is a RFC for the next phase of the QEMU Monitor Protocol project,
in this phase handlers will get fully "structurized".

 I was waiting for the first phase to be merged before sending this, but
as it's already in staging and as this is just a RFC, I've decided to send.

 This series adds the infrastructure needed to accommodate the new style
handlers and ports do_info_balloon() and do_balloon() to QObject style.

 Please, note that I've chosen to stay simple. I already have patches for
QList and advanced stuff (like the 'ninja action' suggested by Anthony) but
for now let's concentrate on design decisions that will impact the protocol
format.

 Besides the 'user_print' approach, it's very important to discuss the
following:

1. Return data
--------------

 For do_info_balloon() I'm always returning a QString. The 'actual' info
could be something else (QDict?), but I think QString is good, because it's
simple.

 Choosing the best set of data types to return is an issue and I don't
think we can have a general rule for this, the solution will be to review
*each* command handler port and be sure we are doing the right thing.

 I hope people don't get bored in reviewing.

2. Return code
--------------

 All handlers will have a return code. For this series they return 0
for success and -1 for error.

 My current plan is that the procotol will *always* emit something like:

 { "__result__": 0, "__data__": { ... } }

 Where the standard keys 'result' and 'data' will be pushed by common
code (monitor_handle_command(), in this case).

 Some people have suggested us to define errors codes, but I dislike this
because I have the impression we will end up defining errors per-handlers,
which is a lot of work and more protocol definitions to maintain.

 Another issue in this subject is that sometimes we will have to do
a not so small refactor to get the proper error code. I mean, sometimes
the functions which the handlers call return void, and those functions in
turn call other functions which also return void. This seem to be the
case of do_balloon(), for example.

 A possible solution is to only return error when it's easy, otherwise we
could always return 0 (which is what we have today), the problem though
is that changing this in the future will cause trouble.

 Suggestions?