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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
