Jay Gagnon wrote:
I'm good with most of this, although a little confused about one thing. I've had the wrong idea about how ECTP was supposed to work in the past, so I wouldn't be surprised if I'm just confused again, but I'm afraid I don't understand why you changed the prof_to_elem behavior. I had it so that we would return an essentially empty instance of the provider that matched that profile, as I thought the idea was that the client would check the CreationClassName and know that this provider implements the profile they wanted. You appear to be finding the appropriate provider and invoking its EnumInstances method. I'm not sure why. Also, won't this present a problem for profiles that don't have EnumInstances?
The DMTF specification defines the following behavior for ECTP, if traversed from an instance of RegisteredProfile to the instance(s) of the profile's scoping class. The result of this request is the list of all instances of the scoping class - which means an EnumInstances on the scoping class. So using an upcall to the EnumInstances function of the scoping class enables a generic implementation of the ECTP provider. What you have been talking about is client logic - but its definitely not the clients responsibility to select the appropriate instances of the profile's scoping class. This knowledge is anchored in the ECTP association. A scoping class always needs to implemented the EnumInstances function. And if there should once be the case that this did not happen then this is either a bug in the specification or in the code ;). -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294