On Mon, Nov 07, 2011 at 01:56:42PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 07, 2011 at 02:52:24PM +0100, Christophe Fergeau wrote:
At this point, I'm not sure what kind of low-level API we want to make available to the library user (by low-level, I mean letting people directly poke at the xmlNode wrapped in a GVirConfigObject instance). That's why I chose not to export them for now, and to make them public if/once they are needed. If you think they should be exported, I'll make the change.
Personally I'd rather we didn't expose libxml2 data types in our public API, since it feels like an admission of defeat in our object model.
Actually, while adding a refcounted wrapper around xmlDoc, I've made more changes/added more helpers which should make it possible to hide these xmlNodePtr from our public API. We would expose either GVirConfigObject or GVirConfigXmlNode as a wrapper around xmlNodePtr and provide helpers to manipulate the xml content they wrap (stuff like new_child, set_attributes, ...)
So if we want to avoid exposing libxml2 types in our API, we should ensure the header file in question doesn't get installed in /usr/include too.
Ah good point, didn't think about this. Time for some noinst_HEADERS in our Makefile.am. I also need to make sure libvirt-gconfig/libvirt-gconfig.h doesn't reference it. Christophe