You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 …
The text was updated successfully, but these errors were encountered:
@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:
The spec mentions:
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 …
The text was updated successfully, but these errors were encountered: