Re: [libvirt] Redesigning Libvirt: Better supporting non-hypervisor agnostic concepts
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