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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 23 Sep 2009 16:19:41 +0100
Nathan Baum <nathan@parenthephobia.org.uk> 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.