Update Type Version Hash to use SHA-256, and details updates based on design discussion #7
Conversation
… design discussion Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com>
…larify some language Signed-off-by: Emerson Knapp <emerson.b.knapp@gmail.com>
|
@wjwwood @clalancette @methylDragon for review |
| Should the message name, including package and namespace, be part of this? | ||
| Consider a situation where you have the same data structure but two different type names, should those two instances have the same hash? | ||
| They are unique when paired with their type name, so it should be ok, but it is a bit weird, perhaps, since we're not using this type hash to check for wire compatibility between differently named types. | ||
| Finally, the resulting filled data structure must be represented in a platform-independent format, rather than running the hash function on the in-memory native type representation. |
There was a problem hiding this comment.
I'm a bit caught up on this part. Not sure how I should represent the TypeDescription for hashing. First instinct is always "dump it to YAML", but I'm not sure if that's the best approach. It doesn't have to be dictated here in the REP but the proposal spec, wherever that lives, will specify this strongly for RIHS1.
There was a problem hiding this comment.
As discussed in weekly meeting, we will represent as JSON (implementation detail: emitted in C by specific libyaml configuration)
There was a problem hiding this comment.
I left one comment that I think can be worded better, but I think this is a good improvement. @wjwwood can you merge this into the main REP please? I don't have permission.
Co-authored-by: Chris Lalancette <clalancette@gmail.com>
Update for ros-infrastructure#358
From discussion today, propose rewrite of "Type Version Hash" section to reflect latest consensus. Main point - use SHA-256 instead of SHA-1. Other clarifying points on how the hash should be calculated.