From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuoUX-0002aP-RX for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:57:01 -0400 Received: from [140.186.70.92] (port=56280 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuoUW-0002aH-J4 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:57:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuoUR-0002ta-Ml for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:57:00 -0400 Received: from cerberus.snarc.org ([212.85.155.21]:47827) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuoUR-0002t1-An for qemu-devel@nongnu.org; Thu, 25 Mar 2010 10:56:55 -0400 Date: Thu, 25 Mar 2010 14:56:52 +0000 From: Vincent Hanquez Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Message-ID: <20100325145652.GA25506@snarc.org> References: <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <20100324134250.38822113@redhat.com> <4BAA6CD9.6060001@redhat.com> <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> <20100324182501.000b69a7@redhat.com> <4BAA86C2.4020701@codemonkey.ws> <4BAB1E21.8080009@snarc.org> <20100325135922.GB10705@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100325135922.GB10705@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: "libvir-list@redhat.com" , qemu-devel@nongnu.org, Luiz Capitulino , Paul Brook , Avi Kivity On Thu, Mar 25, 2010 at 01:59:22PM +0000, Daniel P. Berrange wrote: > > From my point of view, i wouldn't want to write a high level management > > toolstack in C, specially > > since the API is well defined JSON which is easily available in all high > > level language out there. > > It was pretty straightforward for libvirt to talk to the JSON protocol > from C using the YAJL library, so I don't think it is all that much of > a barrier for low level languages like C either. note, that it's not the talking JSON part that's difficult to do in C (it's just midly annoying compare to a highlevel language), but all the other part of a toolstack. Since there's no performance requirements, writing in C is just a bit of a waste ot time, but that's up to the developpers to choose the tools he wants, even if it's not the most appropriate one ;) > If we want to make life easy for app/library developers working against QEMU, > then the far more important aspect is to guarentee stability of all the QEMU > interfaces since that is where all the serious pain occurs over time. if you're talking about the QMP interface then I agree with you. This need to be back/forward compatible as much as possible and stable. the other interface (i.e. the user monitor) has no business beeing backward-compatible though, since it should never be used to talk a RPC. -- Vincent