From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKHDn-0001Kz-Ot for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:36:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKHDj-0001IE-80 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:36:27 -0400 Received: from [199.232.76.173] (port=42352 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKHDj-0001I6-2P for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:36:23 -0400 Received: from ey-out-1920.google.com ([74.125.78.147]:49823) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKHDi-0002Sk-Mt for qemu-devel@nongnu.org; Fri, 26 Jun 2009 15:36:22 -0400 Received: by ey-out-1920.google.com with SMTP id 5so128497eyb.4 for ; Fri, 26 Jun 2009 12:36:21 -0700 (PDT) Message-ID: <4A45232F.50306@codemonkey.ws> Date: Fri, 26 Jun 2009 14:36:15 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file References: <4A412339.5000109@redhat.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43BD5D.80307@codemonkey.ws> <4A43C264.6060803@redhat.com> <4A43D600.8060605@codemonkey.ws> <4A449113.8070907@redhat.com> <4A44CB74.1070808@codemonkey.ws> <4A44E2F3.8050804@codemonkey.ws> <5b31733c0906261036o272bcd8xffc0f2e209b778a5@mail.gmail.com> In-Reply-To: <5b31733c0906261036o272bcd8xffc0f2e209b778a5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Avi Kivity , Vincent Hanquez Filip Navara wrote: > On Fri, Jun 26, 2009 at 5:02 PM, Anthony Liguori wrote: > > It answers some of the issues I had with the original protocol > proposal (interruption of multi-line responses by asynchronous > events). What bothers me though is that it's not LL(1) grammar (not a > big problem, but writing LL parsers by hand is much easier) Perhaps you mean LR(1) (i.e. something that can be understood by yacc). When writing parsers by hand, I tend to prefer recursive decent which easily handles LL(k). Fortunately, this grammar is very simple and can be reasonable converted to LR(1). > and not > all floats can be represented (eg. NaN). I'm not sure that's so important. JSON doesn't support NaN. > String is underdefined - does > the syntax represent bytes or characters? If characters then the \nnn > syntax is insufficient. Strings are UTF-8. Based on the definition of string, the only thing needing escaping is ", \\, and \n. Anything else is just cosmetic. My intention was for \nnn to be a single octal byte as an escape. You could certainly use multiple escape sequences to encoding a large UTF character. > There's no syntax for binary data which may > eventually be required (FDT machine description), but that can be > relatively easily added with something like > I don't think binary data is a requirement. An FDT should be transmitted as a tree, not as a binary blob. You could also transmit binary as a list of bytes though. Regards, Anthony Liguori