On Thu, Oct 23, 2008 at 09:40:36AM -0400, Ben Guthro wrote: > > Again congratulations ! I think this also means the next release > > will be a 0.5.0 since this is a major API addition. I still looking > > at the other pending patches though, it would be better to have them > > in the next release ... oh and I want your java bindings and we need > > Python too (and QPid !) :-) > > Great news! > I'm just starting to look at the Python bindings...tryng to wrap my head > around this whole process. Java will come after this, though I haven't > even begun to look at it. As for Qpid... I suppose that will come after > all the others. I've been mostly ignoring this, hoping I wouldn't have > to know the gory details...but I guess that's unavoidable. Yep, the python stuff is seriously mind-bending with the mix of generated and hand-written code. To help you understand it: - libvir.c - hand written API wrappers - libvirt-py.c - auto-generated APi wrappers - libvir.py - hand written Python calling to C wrappers - libvirt.py - merged libvir.py with autogenerated code - generator.py - the code generator - docs/libvirt.xml - automatically extract API signatures - libvirt-python-api.xml - override incorrect API signatures The generator.py can cope with simple functions using API signature info from those two XML files. Sometimes it'll be able to get the python layer right, but not the C wrappers. For these, blacklist them in 'skip_impl' in generator.py. Sometimes it can't get either the C or python layer write - for those blacklist them in skip_function. I suspect you'll need the latter for the callback registering functions. I wouldn't worry too much about exposing the virEventRegisterImpl() function / callbacks in python. People using python are unlikely to be writing their own event loop impl in python - they'll just use glib/qt. The important bit to expose is the register/unregister of the domain event callbacks. Take a look at the way virRegisterErrorHandler() is handled in the python layer as a reasonable guide. As for Java, that's not time critical, since we release Java bindings separately from the main libvirt C/python code releases. Likewise the QPid stuff is separately released. > Dave Lively's patches for HAL, and DevKit have some java bindings > that are mostly done...I think submitting them are still on his > TODO list. Are these the ones you are referring to? I'm still looking & experimenting with the device patches. I think we're getting close to a solution that can be committed, but I'll also need to submit my patches to split the driver out for the daemon to avoid the GPL/LGPL problem introduced by DBus before we can do a release with this merge. Good news is that those patches are almost ready too. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list