* Daniel Veillard <veillard@xxxxxxxxxx> [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.