Improve types in SDK protobuffers
Is your feature request related to a problem? Please describe.
Many of the types used for fields in the GameServer could be made more precise.
Describe the solution you'd like
Duration fields such as GameServer.spec.health.period_seconds could be an actual Duration. This would also get rid of the unnecessary _seconds suffix since the units would be encoded in the type. The unused Duration message could also just be removed now.
GameServer.status.state is a string, even though it is actually a closed set that could be much more precisely constrained to an enum.
GameServer.object_meta.creation_timestamp and deletion_timestamp could be Timestamps, again getting rid of the unnecessary comments about units etc since they are part of the type.
Describe alternatives you've considered Just leaving the protobuffers as they are.
Additional context
Our agones Rust client wraps the GameServer messages so that we can get precise types that inform users at a type level what things are.
@markmandel - These seem like valid suggestions, but we'd have to think about how to do them in a backward compatible way.
Some thoughts:
- Yep, very valid suggestions. Hindsight on things you know now, vs what you knew then is always 20/20 😄
- "GameServer.spec.health.period_seconds" - I would argue that it probably stay as an integer. the CRDs don't have the idea of a Duration, so the smallest unit of measure of time is a second. Making this as a duration might indicate that it can handle sub-second timespans.
- I've no idea how we could do this while maintaining backward compatibility 😬
- For the Rust SDK specifically, I would posit we could translate to a better type system in the layer between generated Rust and the hand written SDK for better ergonomics (we do that in a few places).
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions