-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CoRIM extension mechanisms #96
Conversation
Remove deprecated linters from .golangci.yml, ensuring that their replacements are present. Fix any new lint issues resulting from the same. Signed-off-by: Sergei Trofimov <[email protected]>
Replace a single uint8 bitfield used to keep track of op flags with a flags map that allows tristate flags (true, false, and unset). This reflects flags representation in https://www.ietf.org/archive/id/draft-ietf-rats-corim-02.html Signed-off-by: Sergei Trofimov <[email protected]>
5b2ee02
to
98cded0
Compare
My apologies, my review is getting staggered. I will try to finish by tomorrow or by end of Friday . |
be68025
to
34c09f6
Compare
34c09f6
to
a152ac9
Compare
6894b70
to
23721b5
Compare
23721b5
to
7e9736e
Compare
2c6ad82
to
0e9bfc7
Compare
a7cbf08
to
e8a6d51
Compare
36ef238
to
a60ac55
Compare
Implement struct extension mechanism and add extension points in places specified by https://www.ietf.org/archive/id/draft-ietf-rats-corim-02.html Extensions are implemented via Extensions object that allows registering user-defined structs are extensions. Fields from these user-defined structs are merged into the parent struct that embeds the Extensions object via some custom serialization code (this required updating the cbor dependency to v2.5.0, and go version to 1.19). Extensions also implements Viper*-like accessor methods for convenient access to the extension fields from the parent struct. (* see github.com/spf13/viper) Signed-off-by: Sergei Trofimov <[email protected]>
f7bd658
to
253836f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Left Minor comment but in general good to submit from my PoV
253836f
to
f4b6a7e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks awesome, thanks for the titanic effort.
I have left a few editorial suggestions in line.
Implement an extensions mechanism for entries identified as "type-choice" in the [CoRIM] spec draft 2. This done by defining a common registration pattern for ITypeChoiceValue interface implementations (the interface is often extended for specific extension points). A Register function is used to associate a factory that produces a type choice instance populated with an appropriate value with a CBOR tag. The factory function must be able to handle nil values, resulting in the zero-value for the associated type; aside from the, the range of valid values the factory can handle is type-specific. A couple of the entries indicates as type choices in the spec (rel and role) are in fact extensible enums, rather than types, so they're implemented somewhat differently. The registration function for them just takes the new value and associated name; there is no need for a factory function. Additionally: - add tagged-int-type implementation for class-id - add EntityName type to represent entity-name type choice (entity-name was previously implemented as a string) - add String() method for comid.Role and corim.Role [CoRIM]: https://www.ietf.org/archive/id/draft-ietf-rats-corim-02.html Signed-off-by: Sergei Trofimov <[email protected]>
733f341
to
83a1a5b
Compare
Add documentation on how to use the newly added extensions mechanisms to implement CoRIM extensions. Signed-off-by: Sergei Trofimov <[email protected]>
83a1a5b
to
3cfdf38
Compare
Add mechanisms to allow extending
corim
implementation at the map-extension and type-choice extension points defined by the spec.