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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
