From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJT4M-0005X1-P5 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:03:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJT4H-0005TN-W3 for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:03:22 -0400 Received: from [199.232.76.173] (port=53346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJT4H-0005TB-QC for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:03:17 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:49537) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJT4G-0005sE-Qg for qemu-devel@nongnu.org; Wed, 24 Jun 2009 10:03:17 -0400 Received: by ewy7 with SMTP id 7so1115261ewy.34 for ; Wed, 24 Jun 2009 07:03:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A42200C.6060600@codemonkey.ws> 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> Date: Wed, 24 Jun 2009 16:03:13 +0200 Message-ID: <5b31733c0906240703w47dd47d7x57d6c08c956f0f84@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file From: Filip Navara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: ehabkost@redhat.com, jan.kiszka@siemens.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino , Avi Kivity , Vincent Hanquez On Wed, Jun 24, 2009 at 2:46 PM, Anthony Liguori wro= te: > Vincent Hanquez wrote: >> >> On Tue, Jun 23, 2009 at 05:50:24PM -0500, Anthony Liguori wrote: >> >>>> >>>> this one is mentioned on the website and has been changed recently (ma= y >>>> 2009): >>>> >>>> http://fara.cs.uni-potsdam.de/~jsg/json_parser/ >>>> >>> >>> That's not a jsonrpc library, that's just a json parser. >>> >> >> but this is completly trivial at this point. jsonrpc is a json message p= ut >> in a >> certain way. >> >> now providing there was a maintained library out there, would you use it= ? >> or do you have more concerns that were unanswered ? > > There are two questions to resolve. =A0The first is whether we should con= tinue > with the current direction (line-based protocol) or whether we should swi= tch > to an RPC. =A0The second question is which RPC we should use. I've spent the last 5 years working on different projects that involved text/line-based protocols. In fact my current day job involves working on a program that works with wide variety of such protocols (POP3, SMTP, IMAP, ACAP, HTTP to name a few) and based on my experience I would seriously recommend using an existing RPC protocol instead. While it's simple to design a synchronous protocol like the original POP3 it gets a lot harder with asynchronous protocols like IMAP. Even if you decide for a custom line-level protocol I'd suggest to learn from the past mistakes, more details below. 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: * An event happens while a multi-line response is currently written to the stream. The behavior has to be defined somehow - either by specifying that the multi-line response mustn't be interrupted by asynchronous events or that it can be interrupted, but only on line breaks. This issue don't arise with message-based protocols. * Should the asynchronous replies (* EVENT) be tagged (ie. C: " reboot", S: "* reset") when they result from a command issued by the manager? If they are not tagged then it's impossible to find out what (if any) of the commands caused the event when multiple asynchronous commands are in progress. That's what basic IMAP does (as specified by RFC 3501). What IMAP did wrong [1] is that even the basic responses to commands like SEARCH are returned as untagged asynchronous notifications, which makes the client implementation hard. Several extensions were later developed to mitigate it and the protocol is now a messy combination of both tagged and untagged responses with no universal syntax. On the other hand, if you tag the events then it's hard for the server (in this case QEMU) to keep track of it and a special syntax still has to be present for truly asynchronous events. * It is necessary to separate the syntax of the data protocol from the semantics of the commands itself. The syntax should be generic enough to support transferring all the necessary information (integers, strings, lists) and simple enough to be parsable even if you receive the data in chunks (assuming a text-based protocol). This is where IMAP went really wrong, since parsing the server responses requires knowning the semantics of ALL the commands. * Many of you asked for facility to negotiate capabilities. I'd suggest the following - the server would lists capabilities by name as a list on connect and the client would be able to specifically enable those that change the semantics of commands. Example: S: + OK QEMU 0.10.50 QMP 0.1 (pci-addr, x-some-extension) C: enable pci-addr S: + OK pci-addr extension enabled The "enable" command would optionally allow for a list to be specified, to enable more extensions at once. Best regards, Filip Navara [1] ...according to large amount of people with the exception of Mark Crisp= in.