[Top][All Lists]

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

Re: [PATCH] schemas: Add vim modeline

From: Paolo Bonzini
Subject: Re: [PATCH] schemas: Add vim modeline
Date: Mon, 3 Aug 2020 10:41:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0

On 31/07/20 17:44, Daniel P. Berrangé wrote:
> I'd consider the runtime protocol separately. In terms of what's on the
> wire, we use genuine JSON format. The runtime problem is simply that JSON
> standard is useless when it comes to integers, leaving behaviour undefined
> in the standard if you exceed 53 bits of precision. So there's no way to
> reliably parse unsigned 64-bit integers. Given that QEMU needs to pass
> uint64 values, JSON was simply the wrong choice of format for QMP.

JSON's 53-bit precision was not part of RFC4627, which was the JSON
specification in 2010.  They say hindsight is 20/20, but referring to
RFC7159 which would come 4 years later is rewriting history, not hindsight.

> There's a 3rd aspect which is our source code that deals with JSON, where
> we defined some JSON extensions to make it easier for C code to construct
> JSON documents for sending over the wire. Back when we did this, it was a
> reasonably good idea as no obvious alternative existed for this problem.
> Today, I would just suggest using GLib's  GVariant feature, which solves
> the same problem for GLib's DBus APIs.

Many years ago actually I tried replacing QObject with GVariant.  I'm
pretty sure the code for that experiment is lost but it took me just a
couple days so it could be redone.  The only issue was that QObjects are
mutable so some instances of QString had to be replaced with GString.

(A small part of it was merged as commit
9bada8971173345ceb37ed1a47b00a01a4dd48cf for unrelated reasons).

> It is a shame we didn't just use DBus back in the day as that's a well
> specified, simple protocol that would have done everything we needed,
> including the ability to actually represent integers reliably. We
> would be able to trivially talk to QEMU from any programming language,
> and use common DBus code-generator tools instead of writing code
> generators ourselves.

Not really, DBus doesn't provide the extensibility that we get from
optional arguments in commands and optional fields in structs.  Again,
we may discuss the QMP protocol itself, but JSON *was chosen for a reason*.


reply via email to

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