[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Daniel P. Berrange
berrange at redhat.com
Thu Mar 25 15:07:20 UTC 2010
On Thu, Mar 25, 2010 at 02:56:52PM +0000, Vincent Hanquez wrote:
> On Thu, Mar 25, 2010 at 01:59:22PM +0000, Daniel P. Berrange wrote:
> > > From my point of view, i wouldn't want to write a high level management
> > > toolstack in C, specially
> > > since the API is well defined JSON which is easily available in all high
> > > level language out there.
> >
> > It was pretty straightforward for libvirt to talk to the JSON protocol
> > from C using the YAJL library, so I don't think it is all that much of
> > a barrier for low level languages like C either.
>
> note, that it's not the talking JSON part that's difficult to do in C (it's
> just midly annoying compare to a highlevel language), but all the other part of
> a toolstack. Since there's no performance requirements, writing in C is just a
> bit of a waste ot time, but that's up to the developpers to choose the tools he
> wants, even if it's not the most appropriate one ;)
>
> > If we want to make life easy for app/library developers working against QEMU,
> > then the far more important aspect is to guarentee stability of all the QEMU
> > interfaces since that is where all the serious pain occurs over time.
>
> if you're talking about the QMP interface then I agree with you. This need to
> be back/forward compatible as much as possible and stable.
>
> the other interface (i.e. the user monitor) has no business beeing
> backward-compatible though, since it should never be used to talk a RPC.
I agree apps shouldn't use it for RPC, but admins using the interactive user
monitor are just as deserving of stable commands & args.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list