I think there are minor quirks with some of our protobuf files and definitions. Nothing is broken, but some best practices and guidance to be consistent within the project could be applied. Some rules especially apply to ensure multi-language compatibility. These are a few points to consider, there are others:
Those rules and others are from both Uber Styleguides and Googles Protocolbuffer Style Guide:
https://developers.google.com/protocol-buffers/docs/style
https://github.com/uber/prototool/blob/dev/etc/style/uber1/uber1.proto
https://github.com/uber/prototool/blob/dev/style/README.md#enums
As always "consistency is key" and we might like to define our own style and best practices for cloudstate. Perhaps our "Formal Spec" #119 Draft-PR could be used to address these issues. Therefore I leave the PR #511 as a Draft-PR to track changes and collaborate on succeeding changes on other places in the code or documentation.
Also, we could use a linter to ensure consistency (buf).
I think there are minor quirks with some of our protobuf files and definitions. Nothing is broken, but some best practices and guidance to be consistent within the project could be applied. Some rules especially apply to ensure multi-language compatibility. These are a few points to consider, there are others:
Those rules and others are from both Uber Styleguides and Googles Protocolbuffer Style Guide:
https://developers.google.com/protocol-buffers/docs/style
https://github.com/uber/prototool/blob/dev/etc/style/uber1/uber1.proto
https://github.com/uber/prototool/blob/dev/style/README.md#enums
As always "consistency is key" and we might like to define our own style and best practices for cloudstate. Perhaps our "Formal Spec" #119 Draft-PR could be used to address these issues. Therefore I leave the PR #511 as a Draft-PR to track changes and collaborate on succeeding changes on other places in the code or documentation.
Also, we could use a linter to ensure consistency (buf).