On Wed, Mar 07, 2007 at 02:56:47PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
> This sounds too variable, adding an entry point per capability of
>some of the hypervisor available will lead to just too many entry points
>once the set of virtualization engines and associated benefits increase.
>That's one of the places where I feel wy more comfortable returning an
>XML description which can then be augmented as more features are added.
But this API is _precisely_ designed to be extensible. The
virCapabilities structure is not accessible to callers (unlike, say,
virNodeInfo), except through accessor functions. We can add accessor
functions in future.
Returning XML just punts the problem elsewhere. Now clients need to
worry about parsing the XML, and there's no real guarantee that the XML
won't change in a way which is incompatible with the clients. Whereas
by using ordinary functions we have that guarantee.
It's easier to make that garantee at the XML level in my opinion.
And adding pile of accessor functions for a struct that you don't feel
you can define well enough to export is not the way I like to define APIs.
Sorry, we disagree.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/