Marvin Theimer wrote:
Agreed. Also, one possibility is to explicitly specify some of the commonly occurring “semi-bound” scenarios, such as “any x86” architecture. I’m not familiar enough with the CIM world to know if they can provide us with guidance on how to solve the problem in general.
The problem with CIM (certainly up to the most recent release, 2.12) is that they model processor types as a pair: (enum value, string) with the string being used only when the enum is "Other". Moreover, the only matching model that you can have using such a model is exact matching; for example, there is no concept that "80386" (the string rendering of value 5 for the CIM_Processor.Family field) is effectively subsumed by "80486" (value 6). Given that, I'd say that while CIM is a nice catalog of processor types (particularly given that someone else is maintaining it ;-)) it's utterly impossible to use for resource selection since the one thing you can say for sure is that people won't match the processor types precisely. What we'd need is some kind of partial ordering (or set of POs, I fear) that allows inexact matching of processor types, but that is itself quite a bit of work (and it's ongoing work too). And such relations are not at all clean to describe in CIM either; although they've got a rich relation model, they're about relating classes and not values of enumerations. Fixing the model that way would entail a major change to the CIM core itself I think, and not just defining more classes on top. Either that or changing the specification of the processor part of CIM to model processor families as classes, which would be very disruptive to what is a pretty static (and hence widely deployed) of CIM. And IIRC, CIM's OS types (CIM_OperatingSystem.OSType) suffer from the same problem. (If I have a binary that works on Win2k, I'd expect it to be fine on WinServer2003 for example, but that's not information captured within CIM.) CIM does description of what is out there well. But it's a very poor base for anything with much richer semantics than equality. I hope this message explains why adequately. Donal.