On 07.06.2017 07:49, Martin Pitt wrote:
Hello Richard,
Richard W.M. Jones [2017-05-31 18:00 +0100]:
> I agree with others that as things stand you will need a REST or DBus
> or similar API added to libvirt.
>
> However have you considered using gobject-introspection to generate
> new "Payload" types automatically?
This doesn't fundamentally change the picture here. Our JavaScript runs in the
browser, so on that side GI doesn't help. What we could do is to dynamically
create some code in the Cockpit module, send it over to the remote machine, and
have it be executed. This could be in Python, which then assumes that
python-libvirt is installed there, or in JS which then assumes that
libvirt-glib and gjs are installed. The latter seems like a stronger
assumption on a server even, but structurally these are pretty similiar.
I. e. GI is not a magic thing to make an API remotable, it just makes it
bindable to different programming languages.
C/GI interfaces also don't map well to D-Bus, i. e. it's not practical to
autogenerate a D-Bus interface for a given GI API. This still works for the
most simple methods that only accept primitive data types and strings, but as
soon as you pass any structs, pointers, function pointers etc. around this
can't be exposed though D-Bus any more without further interpretation on the
server side.
Perhaps not an runtime. But it seems like such a thing could be done at
compile time for the libvirt C API. The libvirt folks do it for their
python bindings, using code generation.
The libvirt Python API behaves a lot like the C API. It's very flat and
not very "pythonic". Which is actually a nice target for us. We could do
something similar with a simple "flat" DBus wrapper of the API ... using
code generation.
What do you think?
Stef