On Wed, May 02, 2012 at 06:35:07PM +0300, Zeeshan Ali (Khattak) wrote:
On Wed, May 2, 2012 at 5:25 PM, Christophe Fergeau <cfergeau@redhat.com> wrote:
Having a per-feature GVirConfigObject seems overkill since it will only be a string wrapper, and a GVirConfigObject wrapping just a string with no node name identifying the type of the node is unusual.
Thats only because I haven't added 2 possible getters of this object. We don't need them right now but they could be added when needed later. I have discussed this with Daniel and he and I both think this 'feature' deserves a separate class.
What would be these getters apart from the already existing _get_name?
+static gboolean add_feature(xmlNodePtr node, gpointer opaque) +{ + struct GetFeatureData* data = (struct GetFeatureData*)opaque; + GVirConfigCapabilitiesCPUFeature *feature; + + if (g_strcmp0((const gchar *)node->name, "feature") != 0) + return TRUE;
Is it expected that "features" nodes are ignored?
? Its the other way around: We ignore other nodes and create objects for 'feature' nodes.
Yes, and I was asking about "feature*S*" nodes ;) Agreed, libvirt is confusing.
Are the 2 kind of nodes (feature/features) two different things that we want to expose differently in the API?
I don't think we need separate classes for both. They both represent the same concept, just that libvirt capabilties xml is a bit inconsistent AFAICT.
Oh, that wasn't a suggestion, I was merely making sure my assumption that feature/features are the same is a good assumption to make, thanks for the clarification. Christophe