where the periods and dashes mess up using those names in Python (and I assume other languages). So, 'NIC.Integrated.1-1-1' violates "naming rules for supported...programming languages."
So¸ that brings me to this idea. Do I understand correctly that underscores will NEVER be used in a name, so my Python API could access
system_object.Chassis.System_Embedded_1.NetworkAdapters.NIC_Integrated_1.NetworkDeviceFunctionand then my API, behind the scenes, would convert all those underscores to periods as it walks the tree and finds the proper objects?
The NIC.Integrated.1-1-1 still presents a problem because dashes are not valid in Python identifiers. I suppose I could get really crazy and make dashes double underscores: NIC_Integrated_1__1__1, and convert __ to -, but that seems a bit excessive.
Any better ideas for accessing Redfish names that violate the standard?
Last Edit: Oct 14, 2022 22:33:26 GMT by jkugler: grammar
Unfortunately that clause you referenced is with regards to property names, like "Name" as a property in a resource. It doesn't cover the value of properties or URI segments; segments like "System.Embedded.1" are values of properties and segments in URIs.
Specifically with URI segments, the only rule we have in the Redfish Specification is that RFC1738-defined unsafe characters are not allowed. Characters like "." and "-" are allowed in that RFC. Since these are built from the value of the "Id" property in various resources, the only rules we have here also echo restricting the values to not contain RFC1738-defined unsafe characters.
So, while there's nothing in the specification today that disallows what you're seeing, I do see the problem that it's causing for you in some languages. I think this is the first time I've seen someone use the value of a property to walk the model in this manner. Normally I see code that operates on specific selections from a property reference, similar to something like this:
Root.Chassis.Members["Id"=="System.Embedded.1"].NetworkAdapters.Members["Id"=="NIC.Integrated.1"] I can raise your particular pattern to the rest of the group to see if others have thoughts on this.
Thanks for the clarification. That does make sense. And thanks for the offer to raise the issue. I also thought of this today. Given a URL such as: /redfish/v1/Managers/iDRAC.Embedded.1/EthernetInterfaces/NIC.1 Right now, I can get that via: rf_root.Managers.Members.EthernetInterfaces.Members Maybe I could have my API respond to this: rf_root.Managers['/iDRAC.Embedded.1'].EthernetInterfaces['/NIC.1']Assumption being: If the subscript is a string starting with a slash it 1) assumes it will be found in the Members collection, and 2) it will be a member that is "below" the current URL in the tree.
That feels ugly and elegant all in one. Maybe replacing the underscores is better.
As for your comment:
I think this is the first time I've seen someone use the value of a property to walk the model in this manner.
That's intriguing. I see that as being a good solution, but unless there are corners of Python I do not know (completely possible) I don't think I could use that in a subscript. Pretty sure "Id"=="System.Embedded.1" would simply evaluate to False, which isn't very useful.
As always, thanks for your input!
Last Edit: Oct 17, 2022 21:34:41 GMT by jkugler: grammar
I've had a discussion about this with others. The best course of action at this point would be in the client library to perform character replacements like you thought about earlier. While underscores could be part of URI segments, I don't think you need to be overly cautious with using single underscores vs double underscores; a simple single character replacement should suffice real-world scenarios. So, when the library encounters a name with underscores, it'll need to do some sort of lookup to convert it back to the proper string for URI segment. So, converting something like "NIC.Integrated.1-1-1" to "NIC_Integrated_1_1_1" would be good.
I think if we had considered these types of libraries when Redfish was first being defined, we probably would have been much more firm with regards to URI construction rules and identifiers.
One very important thing to realize in your implementation is that you're parsing system-specific IDs in your actual code, which for compatibility reasons isn't really something you want to do. Other systems will have VERY different ID topologies compared to what you have above, and if you want to support more than one system-class in redfish, you'll need to adapt to some kind of iteration or filtering of the collections. There is a new specification in process for RedPath, which has a very similar behavior to what you're doing, but very intentionally omits the specific instance IDs, so your code would turn into the equivalent of:
but that would require you in python to overload some of the array subscript parameters rather than solely relying on __attr__ in your classes, but you'll note that there are no specific URI Ids, which would resolve the issue posed above.
Thanks for bringing that up. I have thought about that, and realize I'll mostly likely need to use Member or some such if I want to be cross-vendor in my code. Some of our code attempts to be cross-vendor, other code punts and has vendor-specific branches, so when it's vendor-specific, being able to specify the vendor-specific IDs would be nice.