I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later' tell the
application developper 'my time is more important than yours' and not
really something I like to carry to the API users.
The main goal of libvirt remains to provide APIs needed to unify the
development of the virtualization layers. Having APIs which makes
sense only for one or 2 virtualization engines is not a problem in
itself, it just raises questions about the actual semantic of that API.
If that semantic is sound, then I see no reason to not add it, really
and we actually often do.
Yeah, but the problem we're facing is, I want there to be an API added
to the management layer as part of the feature commit in qemu. If there
has to be a discussion and decisions about how to model the API, it's
not going to be successful.