From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqTy6-0004qG-C1 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 11:41:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqTy1-0004oV-Jg for qemu-devel@nongnu.org; Wed, 23 Sep 2009 11:41:21 -0400 Received: from [199.232.76.173] (port=51650 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqTy1-0004oP-EC for qemu-devel@nongnu.org; Wed, 23 Sep 2009 11:41:17 -0400 Date: Wed, 23 Sep 2009 12:40:59 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree Message-ID: <20090923124059.0fa2680a@doriath> In-Reply-To: <1253719181.24147.84.camel@localhost.localdomain> References: <20090921224430.610da97b@doriath> <4AB98034.3060608@codemonkey.ws> <20090923095701.GE29269@redhat.com> <4AB9FF35.9090208@redhat.com> <4ABA254A.3090703@gnu.org> <4ABA2AD2.3040005@redhat.com> <1253719181.24147.84.camel@localhost.localdomain> 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: Nathan Baum Cc: Paolo Bonzini , Avi Kivity , qemu-devel@nongnu.org On Wed, 23 Sep 2009 16:19:41 +0100 Nathan Baum wrote: > On Wed, 2009-09-23 at 17:04 +0300, Avi Kivity wrote: > > On 09/23/2009 04:40 PM, Paolo Bonzini wrote: > > > On 09/23/2009 12:57 PM, Avi Kivity wrote: > > >> On 09/23/2009 12:57 PM, Daniel P. Berrange wrote: > > >>>> Ignoring the dos-ism, since you can parse JSON with a regexp, why > > >>>> do we > > >>>> need explicit message boundaries? > > >>> I think it would be nice to be able to assume that each JSON message > > >>> will not cross a line-end boundary. Whether we use CRLF, just CR or > > >>> just LF I don't mind. Its much easier to search for a message boundary > > >>> by just doing strchr('\n') than having to actually parse the JSON or > > >>> use a regexp at that point. > > >> > > >> A good parser will consume exactly enough characters to make up an > > >> object or let you know if it needs more. I don't think using a regexp is > > >> warranted. > > > > > > Agreed, regexes are unnecessary. Also because a regex cannot parse > > > JSON; it can only detect _some_ invalid JSON inputs, and then only if > > > you're given an already complete input. > > > > > > In other words, there are Javascript JSON parsers that are just "match > > > a regexp and run eval on the input", but the actual parsing is done by > > > the Javascript interpreter using eval. The regexp is just avoiding > > > the security problems that are inherent in eval. > > > > On the other hand, the two parsers I looked at only accept a string as > > input, not a stream (strangely, one of them internally converts the > > string to a stream, but doesn't expose the stream interface), so record > > termination might be helpful to parsers. Would be best not to rely on > > it in the server, though. > > Relying upon a newline to terminate is also useful in environments where > it is difficult or even impossible to turn off line-buffered mode. > > I sometimes have this problem when trying to consume the human-readable > monitor from a pipe; if I can't disable line-buffering, I don't see > "(qemu) " until I've entered the next command, which can be an > inconvenience. > > I strongly agree that the server shouldn't rely on the line endings. The > server should accept any valid JSON syntax, being "liberal in what it > accepts, and conservative in what it sends". Right now it doesn't even accept input in json (and relies on '\n' or '\r' as end of line), but I will update the spec to follow these guidelines.