On 11/14/2017 06:25 PM, Daniel P. Berrange wrote:
The problem(s) ==============
As mentioned earlier, if an application is only concerned with managing of KVM (or other stateful drivers running inside libvirtd), we have scope to be able to expose a fully asynchronous management API to applications. Such an undertaking would effectively mean creating an entirely new libvirt client library, to expose the asynchronous design, and we obvious have to keep the current library around long term regardless. Creating a new library would also involve creating new language bindings, which just adds to the work. Rather than undertake this massive amount of extra work, I think it is worth considering declaring the RPC protocol to be a fully supported interface for applications to consume.
I don't think this a good idea.
There are already projects which are re-implemented the libvirt client API directly ontop of the RPC protocol, bypassing libvirt.so. We have always strongly discouraged this, but none the less it has happened. As we have to maintain strong protocol compatibility on the RPC layer, it is effectively a stable API already.
And we discourage that for a reason. For instance, our client library does some checks before anything hits the RPC layer, or sets up a state (remoteAuthSASL()). Also, the client library encapsulates two or more calls into a single function: remoteDomainCreate() for instance. Michal