Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)

["Marc-André Lureau" <marcandre.lureau@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

Hi

On Tue, Sep 22, 2020 at 9:08 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 22/09/20 18:35, Marc-André Lureau wrote:
> > The D-Bus specification doesn't detail versioning much. What is
> > recommended is to have the version number as part of the interface name
> > (kinda like soname):
> > http://0pointer.de/blog/projects/versioning-dbus.html (this is
> > documented in several places iirc)
> >
> > So a QEMU D-Bus interface could have a name like org.qemu.Qemu51,
> > org.qemu.Qemu52.. for example, if we can't provide better API
> stability...
>
> That would be a problem for backports.
>
>
Yes..  Backports could expose a subset of the new version interface? Or the
interface can be divided for each Qmp command. (unorthodox)

It seems to me that the bindings issue is only a problem if we insist on
> having positional arguments like we do for C, but if we can avoid
> functions with a zillion arguments we could.  For example in Rust, it's
> idiomatic to use the builder pattern
>
>     let thread = thread::Builder::new()
>         .name("foo".into())
>         .stack_size(65536)
>         .spawn(run_thread)?;
>     thread.join()?;
>
> and I think the same would work in Go or even C++.  It would look like
>
>    qapi::qga::commands::GuestShutdown::new()
>        .mode("halt")
>        .invoke_on(qapi_channel)?;
>
>
Or simply use the same approach as qapi-rs (
https://github.com/arcnmx/qapi-rs) which is  simply generating data
structures based on the schema, and not binding commands to Rust functions
for ex.

qga.execute(&qga::guest_shutdown { mode: Some(GuestShutdownMode::Halt) })

Less idiomatic, but it also works around the optional arguments and
ordering issue.

In both cases, the client interface should be versionized (since some
fields may be added or becoming optional, return value may appear etc), and
only at runtime can you actually verify what is actually supported.

In Python, you can use keyword arguments and there are even keyword-only
> arguments ("def f(*, key1, key2)"), like
>
>     qapi.qga.GuestFileOpen(path="/etc/passwd").invoke_on(qapi_channel);
>
>
Yes, the python binding will have a similar issue. And if we want to add
typing to the mix, representing everything as a dict is not going to help
much. Fortunately, there are other options I believe. But I would rather
aim for the obvious, having non-optional & ordered arguments, and
interface/methods versioning.

When you do something like this QMP-style APIs are not a problem.
> FlatBuffers is another serialization format that supports this kind of
> extensibility (https://google.github.io/flatbuffers/ explicitly compares
> it to JSON, even).
>

Well, I wouldn't say it's not a problem. It makes working with QMP as a
client quite an unpleasant experience overall imho...

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 4273 bytes --]