On Tue, Nov 04, 2008 at 05:21:50PM +0100, Stefan de Konink wrote: > Daniel P. Berrange wrote: > >On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote: > >>Last time *your* argument was that the API would get too big. Now why > >>isn't that argument valid anymore? I'm honestly asking for an > >>explanation on this point, and I do expect you have it. > > > >You are confusing internal API with external API. The external API has > >scalability issues because it is a long term supported ABI. The internal > >API size is irrelevant because we can & will change that at will. The > >domain XML handling API is internal only for in-tree drivers. So there > >has been no change in policy wrt to the external API > > Is an external tool able to use the internal XML handling (from a C > perspective?) or isn't this code exported to the shared library? No, the internal APIs are only intended for use by code that is part of libvirt source tree. While some of the internal APIs may appear in the shared library, they are strictly for private use by the libvirtd daemon because we can make no guarentee that they will work across even bug-fix releases of libvirt. We are working on enforcing the privacy of internal APIs using better linker scripts to control symbol visibility. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list