[Libvir] ruby bindings
Hi, Is there any chance you are considering the addition of ruby bindings for libvir? I have been considering writing my own ruby wrappers around Xen's lowlevel libraries but if libvir is a higher-level more stable API perhaps it would make more sense for me to wrap around libvir. If you are not working on ruby bindings I will do so myself and eventually provide patches. Are you in a position to state yet whether libvir is likely to be continually developed and a key part of the Fedora/RHEL virtualization? I immediately see some missing functionality (migration), I assume the eventual goal is to support all features of Xen and that it is just missing because of the very young state of the project? Thanks!
On Tue, Jan 03, 2006 at 07:33:57PM -0500, Fraser Campbell wrote: Hi !
Is there any chance you are considering the addition of ruby bindings for libvir?
yes, why not.
I have been considering writing my own ruby wrappers around Xen's lowlevel libraries but if libvir is a higher-level more stable API perhaps it would make more sense for me to wrap around libvir. If you are not working on ruby bindings I will do so myself and eventually provide patches.
I now provide python bindings, I see no problem providing ruby ones too, I expect those to be activated by configure flags and detection of the available runtime. In general (i.e. other projects) I think I'm known to say "I take patches" quite often, I don't see why I would change this with libvir :-)
Are you in a position to state yet whether libvir is likely to be continually developed and a key part of the Fedora/RHEL virtualization?
Positively yes, we want to ship libvir in RHEL, and of course Fedora too.
I immediately see some missing functionality (migration), I assume the eventual goal is to support all features of Xen and that it is just missing because of the very young state of the project?
yes, also because the methodology of control of the Xen engine was unclear but as Anthony Liquori pointed out it is possible to do this via the HTTP access to xend. Another point is that I would like libvir to be potentially available for other emulation technologies, but I don't think we should limit to a strict subset. Sounds good ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
I have been considering writing my own ruby wrappers around Xen's lowlevel libraries but if libvir is a higher-level more stable API perhaps it would make more sense for me to wrap around libvir. If you are not working on ruby bindings I will do so myself and eventually provide patches.
I now provide python bindings, I see no problem providing ruby ones too, I expect those to be activated by configure flags and detection of the available runtime. In general (i.e. other projects) I think I'm known to say "I take patches" quite often, I don't see why I would change this with libvir :-)
Is libvir-api.xml a standard document type? Mainly I'm wondering if there might be an existing code generator (similar to your generator.py) that would output C code appropriate for building the ruby extension. Thanks, Fraser
On Wed, Jan 04, 2006 at 10:30:23PM -0500, Fraser Campbell wrote:
Daniel Veillard wrote:
I have been considering writing my own ruby wrappers around Xen's lowlevel libraries but if libvir is a higher-level more stable API perhaps it would make more sense for me to wrap around libvir. If you are not working on ruby bindings I will do so myself and eventually provide patches.
I now provide python bindings, I see no problem providing ruby ones too, I expect those to be activated by configure flags and detection of the available runtime. In general (i.e. other projects) I think I'm known to say "I take patches" quite often, I don't see why I would change this with libvir :-)
Is libvir-api.xml a standard document type? Mainly I'm wondering if there might be an existing code generator (similar to your generator.py) that would output C code appropriate for building the ruby extension.
No, that's just something I cooked up for libxml2, and reused in various other projects. If autogenerated API 'feel' good at the Ruby level then I would suggest to use the .xml as the input and build a generator, it will avoid errors, and reduce your maintainance work as we grow the libvir API. The XML format is dead simple and as it has been in use for libxml2 for years it's unlikely it will change (I may just add the version of the lib where an entry point was added as an extra optional attribute at some point). Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (2)
-
Daniel Veillard -
Fraser Campbell