On 07.06.2017 11:02, Daniel P. Berrange wrote: > On Wed, Jun 07, 2017 at 10:47:25AM +0200, Stef Walter wrote: >> 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. > > I see no problem with mapping almost all of the libvirt API into DBus, as > the DBus method call + signal concepts are very similar to the libvirt RPC > call and event concepts. The place where you would have trouble mapping > to DBus is the stream support as that has no equivalent in DBus, and there's > no efficient workaround to deal with it that I can imagine. Good to know. FWIW, DBus supports FD passing. And Cockpit supports FD passing over DBus: https://github.com/cockpit-project/cockpit/pull/5992 But I agree that any such wrapping of libvirt APIs involving streaming in DBus FD passing would probably wouldn't be auto-generated. Cheers, Stef
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
