On 03/24/2010 07:25 AM, Paul Brook wrote:
I can't quite see what such a libqemu would buy us compared to straight
QMP.
Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common protocol that already has convenient bindings in most
languages. If it's hard[1] for third parties to bind QMP to their favourite
language/framework then IMHO we've done it wrong.
You can't have convenient bindings to an RPC in C because it doesn't
support dynamic dispatch. With most types of RPC, you have an IDL
description and a code generator.
But regardless of that, there are advantages to us providing a libqemu.
The biggest one is that we can standardize transport implementations
that include discovery mechanisms.
If the core of libqemu provided an extensible transport interface, and a
generic QMP request/completion mechanism, in a Python binding, you would
never use the IDL generated wrappers but instead use dynamic dispatch to
invoke arbitrary QMP requests.
But the advantage is that if libvirt provided an API for a QMP transport
encapsulated in their secure protocol, then provided the plumbed that
API through their Python interface, you could use it for free in Python
without having to reinvent the wheel.
Regards,
Anthony Liguori
Paul
[1] Hard compared to any other sane RPC mechanism. Some languages make
everything hard :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list