From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ9b8-0001hR-5R for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:15:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ9b1-0001d7-Q5 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:15:53 -0400 Received: from [199.232.76.173] (port=59392 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ9b1-0001d3-LG for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:15:47 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47746) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ9b0-0004OF-TW for qemu-devel@nongnu.org; Tue, 23 Jun 2009 13:15:47 -0400 Date: Tue, 23 Jun 2009 14:15:39 -0300 From: Luiz Capitulino Message-ID: <20090623141539.32c87e26@doriath> In-Reply-To: <4A40D834.1000602@redhat.com> References: <20090623012811.53a62493@doriath> <4A40989C.1050805@redhat.com> <20090623100615.464404c8@doriath> <4A40D834.1000602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org On Tue, 23 Jun 2009 16:27:16 +0300 Avi Kivity wrote: > 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? Only for now, as you noted in another email command porting/additions should be NACKed if not properly documented. > > 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. Yes. > >> 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. Ok, you suggested a format I'm probably going to use. > >> 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. >