Differences
This shows you the differences between the selected revision and the current version of the page.
| tech:upcall_mechanism 2009/10/08 07:39 | tech:upcall_mechanism 2009/10/09 10:50 current | ||
| Line 56: | Line 56: | ||
| If you enter material here for discussion, please sign it (the easy way is the pen icon on the wiki edit. --- //[[k.schopmeyer@swbell.net|Karl Schopmeyer]] 2009/10/08 14:55// | If you enter material here for discussion, please sign it (the easy way is the pen icon on the wiki edit. --- //[[k.schopmeyer@swbell.net|Karl Schopmeyer]] 2009/10/08 14:55// | ||
| + | |||
| Line 64: | Line 65: | ||
| Personally I really like the idea of using a cim class to provide this information in that it requires nothing more than defining the class and its place in the cim class hierarchy. It has the advantages of a) being completely general so that it applies to all providers, b) being flexible in that new information can be added by i) growing this class in the DMTF, or ii) extending the class for particular CIM Servers. The providers interfaces can then elect to either let the provider writer use this class directly as when requiring information from the server or create apis that would then use the class to actually get the information. To me it makes maximum use of what we already have, a data model and a means of providers requesiting information for that model (the current upcalls to the server). | Personally I really like the idea of using a cim class to provide this information in that it requires nothing more than defining the class and its place in the cim class hierarchy. It has the advantages of a) being completely general so that it applies to all providers, b) being flexible in that new information can be added by i) growing this class in the DMTF, or ii) extending the class for particular CIM Servers. The providers interfaces can then elect to either let the provider writer use this class directly as when requiring information from the server or create apis that would then use the class to actually get the information. To me it makes maximum use of what we already have, a data model and a means of providers requesiting information for that model (the current upcalls to the server). | ||
| - | However, I can understand that there are a number of negatives to this including a) possible overhead, b) implications of creating a class that is provider specific rather than designed for the general client, c) the time to get it through the DMTF, etc. --- //[[k.schopmeyer@swbell.net|Karl Schopmeyer]] 2009/10/08 15:19// | + | However, at this point this is more of a personal whim and I can understand that there are a number of negatives to this including a) possible overhead, b) implications of creating a class that is provider specific rather than designed for the general client, c) the time to get it through the DMTF, etc. --- //[[k.schopmeyer@swbell.net|Karl Schopmeyer]] 2009/10/08 15:19// |
| ========================== | ========================== | ||
