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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
