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

Code cleanups prior to stabilizing protobufs feature #1348

Open
2 tasks
cdisselkoen opened this issue Dec 2, 2024 · 5 comments
Open
2 tasks

Code cleanups prior to stabilizing protobufs feature #1348

cdisselkoen opened this issue Dec 2, 2024 · 5 comments
Labels
internal-improvement Refactoring, minor performance improvement, or other changes that Cedar users may never notice

Comments

@cdisselkoen
Copy link
Contributor

Describe the improvement you'd like to request

The code for the protobufs experimental needs several small cleanups before stabilization. At a minimum,

Describe alternatives you've considered

No response

Additional context

No response

Is this something that you'd be interested in working on?

  • 👋 I may be able to implement this internal improvement
  • ⚠️ This feature might incur a breaking change
@cdisselkoen cdisselkoen added the internal-improvement Refactoring, minor performance improvement, or other changes that Cedar users may never notice label Dec 2, 2024
@john-h-kastner-aws
Copy link
Contributor

john-h-kastner-aws commented Dec 2, 2024

we also need to carefully consider what implementation details the protobuf format effectively makes public. E.g.: #1345 (comment)

The protobuf format is based on our internal structures rather than our external data formats. This is fine for diff testing, but not necessarily for public consumption. The validator structures in particular contain a lot of details that users shouldn't be aware of.

@john-h-kastner-aws
Copy link
Contributor

Linking #1286 and #1352

@john-h-kastner-aws
Copy link
Contributor

Another note #1366 (comment)

@cdisselkoen
Copy link
Contributor Author

We will also need a longer-term solution for the docs.rs build, so as to not require protoc be available on the builder. (The short-term solution is #1434, but that will not work once protobufs are stabilized.)

One possibility is that we can have the build script be aware of when we're building for docs purposes (I think this is #[cfg(docs)] or something similar), and not run protoc. We should be able to ensure we have the same interface for documentation purposes, even without the generated Rust code, eg by replacing function bodies with unimplemented! which doesn't matter during a docs build.

@john-h-kastner-aws
Copy link
Contributor

Linking another comment #1506 (comment)

current entities protobuf assume TC is already computed. We probably want to include a flag to allow the parser to compute TC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal-improvement Refactoring, minor performance improvement, or other changes that Cedar users may never notice
Projects
None yet
Development

No branches or pull requests

2 participants