Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support

[Luiz Capitulino]

On Mon, 25 Jan 2010 15:15:59 +0100
Markus Armbruster <address@hidden> wrote:

> Luiz Capitulino <address@hidden> writes:
> 
> > On Sun, 24 Jan 2010 18:35:14 +0000
> > Jamie Lokier <address@hidden> wrote:
> >
> >> Anthony Liguori wrote:
> >> > >I'd like to be able to connect and be sure not to receive any async
> >> > >messages, from simple scripts with simple output parsing.
> >> > 
> >> > You can't have simple output parsing with QMP.  You need a full JSON 
> >> > stack.  The simplest script would be a python script that uses the 
> >> > builtin json support.  Having async messages means that you'll have to 
> >> > loop on recv in order make sure that the response is a command response 
> >> > vs. an async message.  It's just a few lines more of code so I have a 
> >> > hard time believing it's really a problem.
> >> > 
> >> > But what you probably want is a python QMP library and that would mean 
> >> > you wouldn't need the few more lines of code.
> >> 
> >> You're right.  To be honest, parsing JSON can be done in a single Perl
> >> regexp; a "full JSON stack" isn't much.
> >> 
> >> On that note, it'd be good if the end of a QMP message is framed with
> >> something that can't appear inside the JSON value, without having to
> >> parse the JSON incrementally on each partial read().  There are plenty
> >> of short character sequences to choose from that can't appear.  Some
> >> JSON parsers expect a whole well-formed expression or throw a parse
> >> error - it's what people do over HTTP after all.  So you wait until
> >> you think you've read a whole one, then pass it to the JSON parser.
> >
> >  The Monitor sends a CRLF sequence at the end of each line and I have
> > maintained that behaivor for QMP, but it's hard to _guarantee_ that this
> > sequence won't appear inside a json-string.
> 
> JSON requires control characters in strings to be escaped.  RFC 4627
> section 2.5:

 Excellent.

> >  In practice it doesn't, afaik.
> 
> If it doesn't, then it's not proper JSON, is it?

 My 'doesn\'t' meant: no JSON string we currently generate has CR or
LF in them, as far as I can remember. But even if it happens it's
not a problem, as you clarified.