Re: [Libvir] Questions about the future of libvirt
* Daniel Veillard <veillard(a)redhat.com> [2006-03-04 04:23:40]:
I agree that code refactoring is needed, but I don't want to go
too
far before having a second backend (hopefully I will be able to hack
QEmu soon enough to build one). I'm always a bit vary of too much
abstraction when the code ain't really field tested :-) . But again I
totally agree that the current code must be cleaned up, it's just that
I would prefer to work toward the implementation phase to then be able
to take the right decisions on terms of internal abstract APIs.
Fair enough, I do tend to get to the refactoring a little too quickly
for my own good :-)
W.r.t. plugins, this may be a bit too far away from my taste,
it's
not like there is as many virtualization/emulation frameworks as
hardware species supported on Linux, I would rather not make backend
APIs public and instead see the code in libvirt.
Fwiw, I didn't mention plugins :-). My desire is only to have an
internal design that is clean enough that I can hack on it without
fear of breaking something I didn't notice.
If someone really has a need for extending with proprietary code,
it's LGPL so they can fork it legally, but with all associated
duties :-) . But anyway let's first try to see if we can drive 2
engines with current APIs and it still makes any sense ;-)
Okay. But what about the code reformatting? Even if we don't define a
large internal API mechanism, the current code still needs a uniform
coding style, calling conventions etc. Are you okay to let me do that?
Just so that we can then start working on new implementations on a
single, unified codebase, rather than two codebases fused together
:-).
- Dave.