HE> The current implementation includes the - more academical -
HE> possibility that a client generates an object path by itself,
HE> which is definitely a controversial and not recommended
HE> approach. This is not problematic as long as the client takes care
HE> of all key properties. Only the case that key properties are not
HE> handed over by the client breaks interoperability.
Well, if all of the other key properties are unrelated to the output,
I don't see how it matters. In most cases, we have one true key and
the rest are all identical. If the client fashioned an object path
with two conflicting keys, then it would make sense to reject the
request, and the current implementation would do so correctly.
For the sake of human-driven manual testing, it seems reasonable to me
to ensure that the client provided enough keys to adequately
disambiguate the requested instance from any others. However, I can
appreciate that this is not the common case and that a normal client
should be using only object paths that we have previously generated.
HE> The reason why the CIMOMs do not check the key properties (and
HE> accept not set key properties ) might be, that no CIM spec does
HE> definitely clarify the responsibilities here. So the CIMOM hands
HE> it over to the provider. Which makes sense as the provider is the
HE> one with the implementation logic for the key generation and
HE> always needs a way to identify its real instances out of a given
HE> object path.
Right, which is why I originally had a list of required properties
passed to this function. Because the CIMOM doesn't do its own
checking, we have to do it. Since we know the domain, we should be
able to be intelligent about which properties will always be
identical, and which are really required for disambiguation.
That said, your fix is small and easy, so if you want to write up a
formal patch, I'll apply it.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com