Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

[...]
> The challenge with all these ideas is figuring out whether there's
> a viable way to map them into how we describe the current QMP protocol.
> I don't think there's a especially good answer to do a 100% automated
> mapping from QMP to DBus, while keeping extensibility and also maximising
> strong type checking benefits. There's a tradeoff between extensibility
> and strong typing that needs some intelligent thought on a case by case
> basis IMHO.
>
> For an automated mapping, either we go fully strong typed and accept
> that we'll be breaking DBus interface compatibility continually, or
> we go full weakly typed and accept that clients won't get much type
> validation benefits at build time.
>
> It is the inherant problem with using something weakly typed as the
> master specification and trying to translate it to something strongly
> typed.

I avoid "weakly typed" and "strongly typed", because it means different
things to different people.  "Statically typed" and "dynamically typed"
are clear concepts.

Interfaces defined with QAPI are statically typed.

Serialization / deserialization via QMP works even when the interfaces
on both ends differ in certain limited ways.  It supports more
differences than an RPC transport whose idea of "procedure" has both
feet in the grave of ALGOL 60 could.

At either end of the wire, we need to bridge the gap between a
programming language and the wire format.

At the server end (QEMU), we use the QAPI code generator to bridge from
C, and for the one specific version of the QAPI-defined interface this
build of QEMU provides.

Clients we've left to fend for themselves.  Perhaps it's been a matter
of not understanding client requirements well enough, and chickening
out.

A client could do the same as QEMU does: bridge one specific version of
the QAPI-defined interface.  Could even be done with a suitably extended
QAPI code generator.  A client could also bridge multiple interface
versions, if that us useful.

Regardless of the number of versions bridged, the client could still
talk to servers that use another version, thanks to the QMP transport.

When the server (i.e. QEMU) is newer, any new stuff it may provide is
inaccessible (d'oh).  Also, old stuff may be gone (rare, involves going
through the deprecation process).  Graceful degradation when the client
lags behind too much.

When the server is older than the client, any new stuff the client
actually uses won't work.  The client can use introspection to adjust
itself to older servers.  Graceful degradation again.

Nothing so far precludes a statically typed interface for client code!

The problem isn't "weakly typed" QMP (whatever that may mean), it's that
chasing the evolving QAPI-defined interface with manually written code
is a lot of work.

Libvirt has been doing that work, but you know, "what have the Romans
ever done for us?"

Marc-André's D-Bus experiment explores another way to bridge the gap.
This bridge is generated, not hand-written.  Because the QMP transport
also gets replaced by one that lacks QMP's capability to "mediate"
between versions, client and server versions become tightly coupled.

This isn't due to static typing.  It's due to use of a tool that makes
different tradeoffs than we made with QAPI/QMP.

I'm not fundamentally opposed to adding some QAPI/not-QMP external
interface, but I'd prefer not to end up with the union of disadvantages
and the intersection of advantages.

If QMP no longer matches our requirements, we should replace it
wholesale.