From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTQe-0008UD-7m for qemu-devel@nongnu.org; Mon, 21 May 2012 10:17:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWTQY-00087o-0A for qemu-devel@nongnu.org; Mon, 21 May 2012 10:17:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWTQX-00087Q-L7 for qemu-devel@nongnu.org; Mon, 21 May 2012 10:17:37 -0400 Message-ID: <4FBA4E7A.1020500@redhat.com> Date: Mon, 21 May 2012 16:17:30 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4FB6821A.1080902@redhat.com> <20120521105901.4fbe7363@doriath.home> <4FBA4CE0.2090702@codemonkey.ws> In-Reply-To: <4FBA4CE0.2090702@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: aliguori@us.ibm.com, Stefan Hajnoczi , qemu-devel , Luiz Capitulino , Federico Simoncelli , Paolo Bonzini , Eric Blake Am 21.05.2012 16:10, schrieb Anthony Liguori: > 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. I agree that trying out if an optional argument is accepted or not isn't a nice solution, even though it works and is probably better than adding block-stream-2, ..., block-stream-7. Didn't you say a while ago that adding a command that would return the JSON schema wouldn't be all that hard? Maybe it's the right time to implement it for 1.2. Kevin