On 10/13/2011 08:53 PM, shu ming wrote:
Also I think it would be better if we were able to connect to explicit JSON events, rather than a catch all. THe number of events from QEMU is only going to increase over time& as it does, a 'catch all' becomes increasingly bandwidth wasteful.
If I understand correctly, the idea behind these functions is: the application developers know there is a new QEMU event not known by libvirt library yet. And the developer still requests to add a callback for the new event without the upgrade of libvirt . The functions above provide a QEMU specific way to let the application register the callback by QEMU event without much intervention of libvirt. Then later if we want to promote the QEMU specific way to the libvirt, we should warn the application developer that the QEMU specific way is obsolete.
Yes. Whether or not the qemu registration continues to work after the official libvirt event is added is a different matter, since we've already documented that use of libvirt-qemu is unsupported, but if it is possible to cheaply provide the event through both means, then doing that will allow more clients using the older libvirt-qemu to continue working without recompiling to use the newer libvirt event.
-- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list