From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36986 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0aZo-0001Z0-Oq for qemu-devel@nongnu.org; Fri, 18 Mar 2011 10:22:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0aZm-0003eP-5L for qemu-devel@nongnu.org; Fri, 18 Mar 2011 10:22:51 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:60048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0aZm-0003e4-2P for qemu-devel@nongnu.org; Fri, 18 Mar 2011 10:22:50 -0400 Received: by gxk26 with SMTP id 26so1906297gxk.4 for ; Fri, 18 Mar 2011 07:22:49 -0700 (PDT) Message-ID: <4D836AA1.6070504@codemonkey.ws> Date: Fri, 18 Mar 2011 09:22:25 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 00/15] QAPI Round 1 (core code generator) (v2) References: <1299884745-521-1-git-send-email-aliguori@us.ibm.com> <20110316113428.21c599a3@doriath> <4D80DE65.5080800@codemonkey.ws> <20110316150918.718b425a@doriath> <4D810252.9080300@codemonkey.ws> <20110316162703.21f03bd8@doriath> <4D8116CA.60207@codemonkey.ws> <20110318111044.6daa792d@doriath> In-Reply-To: <20110318111044.6daa792d@doriath> 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: Luiz Capitulino Cc: Markus Armbruster , Adam Litke , qemu-devel@nongnu.org, Avi Kivity On 03/18/2011 09:10 AM, Luiz Capitulino wrote: > > IMO, what's happening here is that you want (or your focus is in) a > different thing. > > Since the beginning we (Markus and I) have focused on having a flexible > wire interface. In its most part, this requirement came from Avi (please > Avi, correct me if I'm wrong), but of course that I agreed with it. > > You've said many times that you don't value non-C consumers that much, > while our focus until today has been on higher level clients. I realize that I've not been careful enough in my language. The problems I'm trying to address are just as applicable to non-C clients. In fact, I've written a Python client library that makes uses code generation: http://repo.or.cz/w/qemu/aliguori.git/commit/a101de2ff0781795f4f7c64ece6e3d48b5783627 It's much simpler than the C interfaces because Python has a bit more awesomeness than C. The only properties of the Python interface that are different than the C is that adding optional parameters to a command handler works okay, but adding optional parameters to a signal still will not work. Regards, Anthony Liguori