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