[Libvir] generator.py -- why?
Daniel P. Berrange
berrange at redhat.com
Tue Aug 29 11:11:46 UTC 2006
On Mon, Aug 28, 2006 at 11:53:09PM -0400, pvetere at redhat.com wrote:
> Hi all. So, I found a bug in the python bindings that I'd really like to fix,
> but when I sat down to do so I quickly found myself mired in a swampy mess of
> code generation: generator.py. :-) Now, I feel compelled to ask -- why don't
> we just have a static libvirt.py file that is WYSIWYG? The generator.py
> program alone is longer than the file it generates, and having a static file
> would not only make the code easier to read, but would also make bug fixing
> much simpler. But, I'm sure there's got to be a good reason for it. :-)
>
> Here's a program that produces the bug I tried to address:
>
> import libvirt
> def get_domain(dom_name):
> conn = libvirt.openReadOnly(None)
> domain = conn.lookupByName(dom_name)
> return domain
> d = get_domain("mydomain")
> print d.info()
>
> This is a fairly typical "factory" pattern I could imagine people using. The
This is a also a very bad pattern to use. Not only is opening a new connection
a fairly heavyweight opertion - it has to connect to xenstore, xend, and fork
fork the proxy server. Now if each time to your get_domain the domain object
returned is associated with a different connection object. This bypasseses the
caching of domain object instances which is done internal to libvirt, degrading
performance still further.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list