From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ617-0006v0-Ga for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:26:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ612-0006q0-Fp for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:26:29 -0400 Received: from [199.232.76.173] (port=39741 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ612-0006ps-8R for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:26:24 -0400 Received: from mx2.redhat.com ([66.187.237.31]:44298) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ611-00005c-Na for qemu-devel@nongnu.org; Tue, 23 Jun 2009 09:26:24 -0400 Message-ID: <4A40D834.1000602@redhat.com> Date: Tue, 23 Jun 2009 16:27:16 +0300 From: Avi Kivity MIME-Version: 1.0 References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> <20090623100615.464404c8@doriath> In-Reply-To: <20090623100615.464404c8@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/11] QMP: Introduce specification file List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org On 06/23/2009 04:06 PM, Luiz Capitulino wrote: >> I don't see you update that file anywhere. In any case, my preference >> would be to have everything in one file. >> > > Sorry, I forgot to mention that I wouldn't include this file > in the patchset. > You mean now, or forever? > Ok, as Daniel also said we will need this. > > The only problem is that I was trying to avoid changing commands' > output too much, because this can turn into a maintenance nightmare. > > Note that we will have to maintain two protocols: the current existing > (user mode) and this new control mode. > I don't see a way out. The current protocol is not machine consumable, but we can't change it. We'll just have to live with it. >> Clients should never make decisions based on the qemu or qmp version. >> Rather, we should provide a facility to query the availability of features. >> > > Right. What about changing 'help' output to only list command names? > Also command subfeatures, when new subfeatures are added. >> >> Maybe add a numeric error code (to be defined by individual commands). >> > > Well, numeric error codes seem redundant in text protocols. At least, > POP3 and IMAP don't use them. > > This may seem contradictory, but although this a low-level protocol, > I feel that text protocols tend to be very descriptive. > Well, the strings are not single words, so the key for the application is "all words until the end of the line". Not too machine friendly. -- error compiling committee.c: too many arguments to function