> > 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? Paul
