qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Luiz Capitulino
Subject: Re: [Qemu-devel] ANN: QEMU Monitor Protocol git tree
Date: Wed, 23 Sep 2009 13:11:23 -0300

On Wed, 23 Sep 2009 18:01:44 +0200
Markus Armbruster <address@hidden> wrote:

> "Daniel P. Berrange" <address@hidden> writes:
> 
> > On Tue, Sep 22, 2009 at 08:56:04PM -0500, Anthony Liguori wrote:
> >> Luiz Capitulino wrote:
> >> >Now the controversial part: it's json based. ;)
> >> >
> >> >I have chosen json because of the reasons already explained by others in
> >> >the original QMP thread. Basically, json is so simple that if we design
> >> >a small protocol from scratch, chances are it will look like json.
> >> >  
> >> 
> >> json is not a deal break.  My main concern was our ability to extend 
> >> json and whether supporting stock json libraries was a hard 
> >> requirement.  I also would like to see a C client library since our 
> >> biggest consumer (libvirt) is based in C.
> >
> > I've googled around quickly and there are at least 5 pieces of C code
> > and/or C libraries that can parse JSON. Hopefully one of them will be
> > sufficient / suitable for libvirt's needs. We'll just need to try it
> > out and see what happens....
> >
> >> >2.1 General Definitions
> >> >-----------------------
> >> >
> >> >All interactions transmitted by Client and Server are json-objects that 
> >> >end
> >> >with CRLF.
> >> >  
> >> 
> >> CRLF?  Really?
> >> 
> >> 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.
> >
> > Daniel
> 
> If the objective is to make life as easy as possible for clients, then
> terminate lines with just LF.

 Okay, but note that the '\r\n' are there because it's what
QEMU does today (look at monitor_puts()).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]