6:33 p.m.
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!
3:35 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:30 p.m.
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
3:10 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6928
days inactive
6929
days old
3 comments
2 participants
participants (2)
-
Daniel Veillard -
Fraser Campbell