[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Re: ANN: QEMU Monitor Protocol git tree |
Date: |
Wed, 23 Sep 2009 12:40:59 -0300 |
On Wed, 23 Sep 2009 16:19:41 +0100
Nathan Baum <address@hidden> 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.
- [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Luiz Capitulino, 2009/09/21
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Markus Armbruster, 2009/09/23
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Luiz Capitulino, 2009/09/23
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Jamie Lokier, 2009/09/23
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Anthony Liguori, 2009/09/23
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Daniel P. Berrange, 2009/09/23
- Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Luiz Capitulino, 2009/09/23
Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree, Luiz Capitulino, 2009/09/23