Karl Czajkowski wrote:
I'd go a step further, and say that these relationships are application specific and not intrinsic to the OS or architecture. The underlying matching system should include some logical combining mechanism, and "user friendly" client-side tools should allow imposition of certain ordering idioms if this is desired. I don't think ANY standards body will capture all of the combinations which matter to applications, unless they produce a logical combination structure and canonically name nearly every combination. ;-)
If I remember right, this is why the only matching semantics that are actually defined for operating system or CPU type by the JSDL spec are "exact match" despite that being not very useful in most cases. Another case that has the same problem is application version; some apps define a sane scheme, but others are just mad (for example, the Linux version scheme where the low bit of the second digit indicates stability status and not actual versioning, and Java product versioning is driven by marketing and not technical utility). Exact matching is the only universal matching plan, but it does not serve users well; if a point release has been done to fix some obscure bug, why should that invalidate a user's job submissions? They probably weren't bitten by that bug in the first place. The best approach for users is for them to only give CPU types, OS types/versions and application versions when they *really* need it, and for them to leave those resource facets unspecified otherwise. Indeed, that works well in highly managed environments (such as those targetted by UNICORE) where applications are things that are installed by admins and users just use them. That's obviously not what everyone wants, but perhaps it is all that can be done interoperably. :-( Donal.