[Qemu-devel] QOM vs QAPI for QMP APIs

[Stefan Hajnoczi <stefanha@redhat.com>]

I need to add a QMP API that lists dataplane threads.  This is similar
to "query-cpus" where the thread IDs are reported.  It allows the client
to bind threads to host CPUs.

I'm inclined to add a "query-iothreads" QMP command:
 * It's easy to implement using QAPI
 * We've developed best practices for QMP APIs
 * We know how to version and make QMP APIs extensible
 * Clients (including libvirt) are used to QMP JSON RPC

But maybe I should use QOM instead:
 * Add a "qom-find-objects-by-class" QMP command (Paolo's idea)
 * Client does "qom-find-objects-by-class IOThread /objects"
 * Client then uses "qom-get" to fetch the thread_id property on each
   IOThread object
 * But we haven't really established how QOM APIs will work

So my question is: should we use QOM as the external API or continue
using QAPI?

I don't think we gain much by switching to QOM other than opening a
whole new design space that we've yet to master.  We'll make plenty of
mistakes just like we did with QMP and QAPI.

Although QOM eliminates the need to implement dedicated QMP commands, it
exposes a more complex model to the client.  Instead of a JSON
command/response model we now expose a general object-oriented namespace
with properties, links, etc.  The client has to make sense of all that
and has to perform multiple qom-list/qom-get/etc commands for something
that would take a single dedicated QMP command.

Maybe I just need some convincing but it seems that QAPI is the simplest
and cleanest way to define external APIs.

Disagree?  Tell me why :).

Stefan