Re: [PATCH 11/19] rust/qobject: add from/to JSON bindings for QObject

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/5/25 11:04, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> These are used by tests.  However it could even be an idea to use
>>> serde_json + transcoding and get rid of the C version...
>> 
>> Tell me more!
>
> QEMU's JSON parser produces a QObject.  To obtain the same effect, we 
> can take JSON-string-to-serde deserialization (implemented by 
> serde_json) and attach it to serde-to-QObject serialization (the thing 
> in patch 5).  That results in a JSON-string-to-QObject function.
>
> Doing it in the other direction (QObject deserializer + JSON-string 
> serializer) produces a QObject-to-JSON-string function.

Yes.

> For a little more information see https://serde.rs/transcode.html.
>
> Note however that there is no support for push parsing, therefore this 
> would not replace the balanced-parentheses machinery in 
> qobject/json-streamer.c, and therefore QMP would still need a minimal lexer.

That push parser...  I never liked it.  First, it's half-assed: it's a
push lexer wed to a pull parser with parenthesis counting.  Second, why
complicated & half-assed when you can do simple & quarter-assed instead?
We could've required "exactly one complete JSON value per line", or some
expression separator such as an empty line.

> Grr... I just remembered about interpolation :/ so no, we still need a 
> parser for libqmp.c.

Right.

Interpolation lets us build QObjects from literal templates with
variable scalars or QObjects interpolated.  More concise and much easier
to read than the equivalend nest of constructor calls.  Drawback: chains
us to our own, bespoke JSON parser.

Out of curiosity: how would we do better than "nest of constructor
calls" in Rust?