qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] schemas: Add vim modeline


From: Daniel P . Berrangé
Subject: Re: [PATCH] schemas: Add vim modeline
Date: Mon, 3 Aug 2020 10:44:37 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

On Fri, Jul 31, 2020 at 07:47:01PM +0200, Paolo Bonzini wrote:
> On 31/07/20 19:20, Daniel P. Berrangé wrote:
> > It also means QMP isn't easily extensible. eg if we used
> > HTTP as our base, then we'd get remote TLS support for free from
> > whatever library we used.
> 
> ... and we would lose events, unless we do something with HTTP/2 and
> streaming responses.  We would also have to pass the TLS certificates to
> whatever library we used (which might even be using openssl instead of
> gnutls).  So it's not that simple, and that's why I'm hesitant to see
> things as a universal improvement without seeing the code.

I didn't mean to suggest that QEMU should use HTTP, I was just
comparing QMP use of JSON vs the common webservices using RST
with JSON.

HTTP/2 streaming is not required for async events though, there's a
variety of ways to do that with HTTP/1.1.

Open a HTTP connection and issue GET for /events, and the server
will then simply not respond until it has an event ready. Once a
event is received, that request is complete. With connection reuse
enabled though, another GET request can be made to wait for the
next event without the overhead of re-establishing the connection.

Alternatively a single HTTP request can be used, but with the response
using chunked event so that it can send back an arbitrary unbounded
amount of data spread over time. The client can receive and process
this data on the fly without waiting for the request to complete.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

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