From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTS9-0001o2-Tb for qemu-devel@nongnu.org; Mon, 21 May 2012 10:19:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWTS2-0008Gt-3p for qemu-devel@nongnu.org; Mon, 21 May 2012 10:19:17 -0400 Received: from mail-qa0-f52.google.com ([209.85.216.52]:58613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTS1-0008Gj-W7 for qemu-devel@nongnu.org; Mon, 21 May 2012 10:19:10 -0400 Received: by qabj34 with SMTP id j34so2061323qab.11 for ; Mon, 21 May 2012 07:19:08 -0700 (PDT) Message-ID: <4FBA4ED9.6010906@codemonkey.ws> Date: Mon, 21 May 2012 09:19:05 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FB6821A.1080902@redhat.com> <20120521105901.4fbe7363@doriath.home> <4FBA4CE0.2090702@codemonkey.ws> <20120521111637.308bdaa6@doriath.home> In-Reply-To: <20120521111637.308bdaa6@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel , Federico Simoncelli , Paolo Bonzini , Eric Blake On 05/21/2012 09:16 AM, Luiz Capitulino wrote: > On Mon, 21 May 2012 09:10:40 -0500 > Anthony Liguori wrote: > >> On 05/21/2012 08:59 AM, Luiz Capitulino wrote: >>> On Fri, 18 May 2012 19:08:42 +0200 >>> Paolo Bonzini wrote: >>> >>>> Modified QMP commands >>>> ===================== >>> >>> As we have discussed on the ML, we're not going to extend QMP commands. >>> >>> I understand your reasoning, and since the beginning I thought this was >>> something useful to do, but we've already settled for not doing this. >>> >>> I also think that we shouldn't have exceptions, as in practice this means >>> we're extending commands anyway. So either, we do it or we don't. >> >> Well, I think we should ask ourselves the following question: >> >> How would a client figure out if the new options are available? >> >> This is the primary reason for not extending existing commands. > > Yes, I know. But if Paolo implements schema introspection, would you > agree on extending commands. > > You seemed to be against even if we had schema introspection. I'm not against it in principle, just in practice. Today, checking whether a command exists is: commands = qmp.query_commands() if 'block-stream' in commands: # has block-stream I have a hard time envisioning how schema introspection can be reasonably implemented in a client. If we really feel it's important to extend commands, I'd prefer something like per-command capabilities. Regards, Anthony Liguori