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(a)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