On 03/23/2010 10:57 AM, Paul Brook wrote:
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.
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to our interface or do we
make use of the functionality that libvirt already provides if they can
plumb our API directly to users.
Regards,
Anthony Liguori
Paul
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list