[Libvir] Questions about the future of libvirt

[David Anderson]

* Daniel Veillard <veillard at 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.