Daniel P. Berrangé <berra...@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.
