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

[Anthony Liguori]

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.

The main advantage of not relying on whitespace terminated messages is 
that it gives us the ability to pretty print the protocol on the wire.  
For instance, I'd rather read:

{ "execute": "info",
  "id" : "32",
  "arguments": ["cpus"]}

Especially when responses get very, very long.

Regards,

Anthony Liguori