On 01/13/2012 02:11 PM, Eric Blake wrote:
> I previously proposed this here:
>
https://www.redhat.com/archives/libvir-list/2011-December/msg00899.html
> although it's been on my wish list a lot longer than that.
>
> Questions: I had the new API take nformats as an int, and return the
> number of populated slots; should I switch this to take *nformats as
> a pointer (being both input and output) with a return value of 0, so
> as to be more consistent with things like virDomainGetMemoryParameters?
>
> I'm not very familiar with writing python bindings, at least not without
> the benefit of copy-and-paste, and I didn't see a good example to copy
> from. Ultimately, I envision that the python API will be something like
> virConnect.domainNativeFormats(self, flags), with a return being
> a python list of strings (where the underlying code calls
> virConnectDomainNativeFormats twice, once to determine the list
> size, and once to determine the list contents), but I'm not sure how
> to go about doing that (I don't know if generator.py can do it, or
> if it needs an override, or what). So I left the python bindings
> undone, and would appreciate if someone else can step in and help.
>
Hmm, why not just include this info in capabilities XML? Might not be as easy
for some simple apps like virsh to consume, but it seems like more of the
proper place to put this.
(sorry if this has been discussed before, I haven't been following
libvirt-list too closely as of late).
Hmm, good idea. We already use capabilities to expose the list of
supported migration URIs, so I'll see about re-spinning this patch into
one that adds the supported names as capabilities, then teaches virsh
domxml-formats to do an XPath scrape of the capabilities XML rather than
needing a new API.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library