Heidi Eckhart wrote:
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 ;).
Understood. That's fine. My tendency to think like a client seems to
have bitten me again. :)
--
-Jay