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