[libvirt] [libvirt-glib 2/3] Add host capabilities API

[Christophe Fergeau]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120502/dc8941df/attachment-0001.sig>