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...