Re: [libvirt] Remotable Libvirt

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.