[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Libvir] generator.py -- why?
- From: "Daniel P. Berrange" <berrange redhat com>
- To: pvetere redhat com
- Cc: libvir-list redhat com
- Subject: Re: [Libvir] generator.py -- why?
- Date: Tue, 29 Aug 2006 12:11:46 +0100
On Mon, Aug 28, 2006 at 11:53:09PM -0400, pvetere 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 -=|
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]