Re: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree

[Nathan Baum]

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".