On Mon, Apr 26, 2010 at 05:34:22PM +0300, Avi Kivity wrote:
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with virtualization/qemu, we want
to steer them far clear of this API. That goes doubly true for application
developers; we want them to be able to use a stable, long-term API and
not have to worry about the nitty-gritty details of the monitor. It's that
latter group that we want to make sure doesn't use this API.
With qmp, we have a stable long term API, and the nitty-gritty details
are easily hidden behind a stock json parser (unfortunately some rpc
details remain). The command line is baroque, but the libvirt xml isn't
so pretty either.
The problem is a user that starts with libvirt and outgrows its
featureset. Do we want them to fall back to qmp?
If were QMP were to be the standard mgmt API, then you are merely inverting
the problem. The problem is now a user that starts with QMP and outgrows
its featureset.
We have two layers in the stack here& neither provides a superset of the
other. As Anthony has mentioned, this has parallels with GTK (libvirt) vs
libX11 (libQMP). Programming against GTK does not give you all the features
you'd have if you programmed against X, but most people do not need them
and this is offset by the benefits GTK gives in portability across OS. GTK
does allow them to get direct access to X if really needed, but most apps
will avoid doing that if at all possible, and when it is found to be
neccessary new APIs are added to GTK so that direct X11 access remains a
short-term hack.
We shouldn't have to frame this as a libvirt vs QMP problem. libvirt uses
QMP for its work, and apps use libvirt API for the vast majority of their
needs. If direct access to QMP is needed we can now provide that for apps
as a short term hack, until suitable APIs are added to libvirt.