From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJuf1-0006Zi-WE for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:31:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJuew-0006Un-G9 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:31:03 -0400 Received: from [199.232.76.173] (port=54556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJuew-0006Ua-7k for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:30:58 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59537) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJuev-0005aS-Pq for qemu-devel@nongnu.org; Thu, 25 Jun 2009 15:30:58 -0400 Date: Thu, 25 Jun 2009 16:30:45 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090625163045.754e85da@doriath> In-Reply-To: <5b31733c0906240703w47dd47d7x57d6c08c956f0f84@mail.gmail.com> References: <4A40FB11.8090100@redhat.com> <4A40FE31.2010007@us.ibm.com> <4A40FFB0.2070905@redhat.com> <4A411FC5.7050701@us.ibm.com> <4A412339.5000109@redhat.com> <4A412659.1080803@us.ibm.com> <20090623220204.GA5612@snarc.org> <4A415C30.7030301@us.ibm.com> <20090624010108.GA6537@snarc.org> <4A42200C.6060600@codemonkey.ws> <5b31733c0906240703w47dd47d7x57d6c08c956f0f84@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Filip Navara Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Vincent Hanquez On Wed, 24 Jun 2009 16:03:13 +0200 Filip Navara wrote: > The current draft specification used a mix of semantics of the > forementioned protocols - error handling based on POP3 (+OK/-ERR), > asynchronous events based on IMAP (* prefix). IMAP-like tagging of > commands was also suggested (to deal with asynchronous commands) and > issues have been raised concerning multi-line responses. Note that all > this gets a bit hairy when you combine it. Just a few issues that come > to mind: Although I think QMP is very close to what QEMU needs, there is no doubt it's not complete. I appreciate your feedback, but I will only go through it if we decide using QMP.