From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuQ2m-00077L-2w for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:50:44 -0400 Received: from [140.186.70.92] (port=50901 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuQ2j-00073r-Md for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:50:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuQ0h-0007Vz-1c for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:48:36 -0400 Received: from mail-pz0-f194.google.com ([209.85.222.194]:58629) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuQ0g-0007Vu-OW for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:48:35 -0400 Received: by pzk32 with SMTP id 32so866814pzk.4 for ; Wed, 24 Mar 2010 05:48:33 -0700 (PDT) Message-ID: <4BAA0A1E.2080805@codemonkey.ws> Date: Wed, 24 Mar 2010 07:48:30 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <4BA962F3.1020107@codemonkey.ws> <201003241225.30442.paul@codesourcery.com> In-Reply-To: <201003241225.30442.paul@codesourcery.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: Paul Brook Cc: "libvir-list@redhat.com" , Alexander Graf , qemu-devel@nongnu.org, Markus Armbruster 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 :-) >