KR> I think all of this can be removed because filter_results() in KR> libcmpiutil should remove the need for this kind of checking.
Yeah, which is really handy.
I can see this becoming an issue later strictly for performance, but I think that this is fine for now and we can reintroduce the optimization (correctly) if we decide it's needed. Now, that you both pick up the filter_results() function, this is a good time to enter this discussion. I agree that the filter_results() function is handy and takes away a lot of checking and distinguishing from the provider. For tiny numbers of returned instances and fast systems, this will not cause any problems. But we should keep in mind,
Good catch Kaitlin :). Dan Smith wrote: that the providers should also scale for a large number of virtual machines. As Dan already mentioned - this approach will become an performance issue later. On the other hand its more the responsibility of the provider - especially for our ones, that handle a lot of subclasses at one time - to filter the returned instances, as the responsibility of the generic association logic. So I want to follow Dan's opinion and keep it for now. But we should add this to our ToDo list and fix as time allows. I suppose this will mean to reorganize the providers a bit and I do not expect a huge effort. -- 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