I think you've definitely touched on the problem with using the CIM model, but I have to imagine that the people discussing these issues in the DMTF working groups have faced exactly the same issue as we're seeing, and the result is that they went for this simple approach. So we can go through the same exercise they did, perhaps with a chance that we arrive at a different approach which allows us more flexibility, but I'm guessing we'd arrive at the same place. How do we keep up (in standardization) with the fast changing world around us? I for one want to make sure that when someone asks me for a particular OS or processor type, that I can understand the "token" that I'm given. -- Chris On 12/6/06 01:28, "Donal K. Fellows" <donal.k.fellows@manchester.ac.uk> wrote:
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.