From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6PvN-0003C5-S9 for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:08:41 -0400 Received: from [140.186.70.92] (port=55382 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6PvM-0003BJ-BF for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:08:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6PvK-0008QH-BM for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:08:40 -0400 Received: from mail-qy0-f188.google.com ([209.85.221.188]:37842) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6PvK-0008QA-7r for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:08:38 -0400 Received: by qyk26 with SMTP id 26so5299258qyk.19 for ; Mon, 26 Apr 2010 08:08:37 -0700 (PDT) Message-ID: <4BD5AC71.4080308@codemonkey.ws> Date: Mon, 26 Apr 2010 10:08:33 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API References: <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> <4BD1ADA2.2050605@redhat.com> <20100423143656.GG17700@redhat.com> <20100426125424.GC16976@shareable.org> <4BD5A26A.90003@redhat.com> <4BD5A46E.9090808@redhat.com> <20100426145450.GB12919@redhat.com> In-Reply-To: <20100426145450.GB12919@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Libvirt , Jiri Denemark , Chris Lalancette , Avi Kivity , qemu-devel@nongnu.org On 04/26/2010 09:54 AM, Daniel P. Berrange wrote: > 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. > I agree with you (for the most part). The one difference here is that libgtk actually implements a full widget kit on top of libX11. That's why people use gtk and not X11 directly. Portability was really an after thought with gtk. If you look at libgtk and libcairo, instead of trying to replicate the features of cairo within gtk, gtk encourages people to use cairo directly for anything beyond the simplest 2d operations. Regards, Anthony Liguori > Daniel >