Skip to content
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

Improve and stabilize the protobuf validation #176

Open
mara-schulke opened this issue Dec 4, 2023 · 2 comments
Open

Improve and stabilize the protobuf validation #176

mara-schulke opened this issue Dec 4, 2023 · 2 comments
Assignees
Labels
complexity::medium Issues or ideas which require some discussion, research and more implementation work component::cli Everything related to the buffrs cli datamodel Changes related to the Datamodel priority::high Urgent change or idea, please review quickly type::feature Shipping or drafting a new feature for this product type::refactoring Changing the inner-workings of buffrs
Milestone

Comments

@mara-schulke
Copy link
Contributor

cc @xfbs

We need to roll out more linting rules and restructure the validation implementation eventually.

@xfbs could you guide tom on this?

@mara-schulke mara-schulke added datamodel Changes related to the Datamodel component::cli Everything related to the buffrs cli priority::high Urgent change or idea, please review quickly complexity::medium Issues or ideas which require some discussion, research and more implementation work type::feature Shipping or drafting a new feature for this product type::refactoring Changing the inner-workings of buffrs labels Dec 4, 2023
@mara-schulke mara-schulke added this to the Stabilization milestone Dec 4, 2023
@xfbs
Copy link
Contributor

xfbs commented Dec 4, 2023

Happy to — let's schedule something.

@tomkarw tomkarw self-assigned this Dec 4, 2023
@xfbs
Copy link
Contributor

xfbs commented Dec 6, 2023

Here's some rules that we have agreed we want.

Keep in mind that we don't want to build something that replaces a linter at this point — we only want to enforce specific rules that only buffers can enforce because they go beyond standard protocol buffer style.

  • The protocol buffer package name should be the same as the buffrs package name, but with dashes (-) replaces with underscores (_)
  • Buffrs packages can be of different types: api, lib, and impl. Buffrs packages which are lib packages should not have any service definitions. Only packages which are api packages should be allowed to have service definitions.
  • File structure should be correct: any file which declares itself as being in mypackage.subpackage must live in the proto/subpackage/ folder. (might already be partially implemented?)

Other ideas:

  • Ident casing: make sure all identifiers in a protocol buffer definition use a common casing, for example:
    • Message names are CamelCase
    • Field names are snake_case
    • Maybe this is not a good idea because a linter should be doing this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity::medium Issues or ideas which require some discussion, research and more implementation work component::cli Everything related to the buffrs cli datamodel Changes related to the Datamodel priority::high Urgent change or idea, please review quickly type::feature Shipping or drafting a new feature for this product type::refactoring Changing the inner-workings of buffrs
Projects
Status: No status
Development

No branches or pull requests

3 participants