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

Clarify Interoperability between binary formats? #385

Closed
flokli opened this issue Aug 28, 2024 · 2 comments
Closed

Clarify Interoperability between binary formats? #385

flokli opened this issue Aug 28, 2024 · 2 comments
Labels

Comments

@flokli
Copy link

flokli commented Aug 28, 2024

The spec mentions:

The required components of a system that supports CEL are:

    The textual representation of an expression as written by a developer. It is of similar syntax to expressions in C/C++/Java/JavaScript
    A binary representation of an expression. It is an abstract syntax tree (AST).
    A compiler library that converts the textual representation to the binary representation. This can be done ahead of time (in the control plane) or just before evaluation (in the data plane).
    A context containing one or more typed variables, often protobuf messages. Most use-cases will use attribute_context.proto
    An evaluator library that takes the binary format in the context and produces a result, usually a Boolean.

It's a bit unclear on whether the intention is to have the binary format be the same across all different implementations, or whether it's ok for it to be evaluator-specific.

I have a usecase where I'd like to be able to send CEL expressions to "configure a system behaviour", and would like to ideally send them in a compact format, as they don't need to be human-readable anymore at this point. However, without such a guarantee the only stable form I can use is the human-readable text form.

I think there's a value for standardizing an exchange format for CEL expressions that works across different implementations. It might however be ok (and desirable) for it to be separate from the internal representation.

Could this be clarified a bit in the docs?

This popped up in clarkmcc/cel-rust#80, along with some hearsay of cel-go potentially moving away from the protobuf dependency for everything …

@TristonianJones
Copy link
Collaborator

@flokli I think what you're asking about is the difference between internal representation and serialization format. Go, Java, and C++ use a native representation of the AST through all stages: parse, type-check, and evaluation. However, all native representations are proto-serializable to support sending CEL programs over the wire and storing them in databases.

For the proto serializable format you can depend on the canonical protos or the v1alpha1 protos which are exact copies of each other. We'll retain backwards compatibility between these formats in perpetuity but will emphasize using the canonical proto as soon as we introduce serializers / deserializers for it in all stacks:

Hopefully, this answers your question. Happy CELing!

@flokli
Copy link
Author

flokli commented Aug 28, 2024

@TristonianJones thanks for the explanation! So using the proto expression encoding to send CEL programs over the wire is definitely a thing.

I'm suggesting to explicitly point this out in the spec, in that quoted section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants