Stef Walter [2017-06-07 10:47 +0200]:
On 07.06.2017 07:49, Martin Pitt wrote:
> 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
Sure, one can always write code to map the libvirt API into a D-Bus API (in C,
the best choice). My point was just that this would require to create,
package, and ship new code on the target machines, which is a very high barrier
for stable OS releases (particularly RHEL/CentOS, but it's not easy at all for
e. g. Debian or Ubuntu either).
Peter and I discussed if we could get away somehow with the existing code/APIs
on stable releases. E. g. a hackish, but maybe workable first step might be to
only use the python-libvirt API for subscribing to desired notifications and
trigger the Cockpit VM module through it, but continue to handle all the
actions through virsh. This subscription/notification code will hopefully be
small enough that it can be sent "through the wire" (cockpit channel) and
executed ad-hoc, without having to actually distribute it on the remote side.