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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/