CloudEvents Expression Language

I want to propose to start a new effort to develop an expression language to filter CloudEvents.

Motivation

One of the main drivers is the ability to have more powerful filtering capabilities in the subscription API, where the existing filter dialect basic is not powerful enough for most of production use cases. I foresee an eventual application of such language in the Discovery API and the Workflow spec.

Expected outcome

Our goal is to develop a spec for an expression language tailored for CloudEvents. Some goals of this language are, but not limited to, the following features:

• Total functional programming language, hence the termination of the evaluation of the expression is always guaranteed
• Type system conform to the CloudEvents type system
• Boolean operators (and/or/nor/xor)
• Comparison operators on the types provided by the type system
• Regex
• Function invocation semantics + basic built-ins (e.g. type assertions/casting,

It’s out of the scope of the effort to develop a generic expression language, hence the input of the expression will always be a CloudEvent.

Notes

• We could help the implementers providing the antlr grammar for it.
• We should implement this language in our sdks (I’m willing to help for java, golang, rust).
• I would prefer to exclude payload filtering from the initial efforts, since I consider it a complex argument (It comes to my mind problems like payload too big, supporting different content types, …)
• We don’t want anything particularly fancy regarding the syntax, so my feeling is that we should a C-like syntax or similar, something familiar for cloud developers out there

[slinkydeveloper]

I managed to sketch some ideas and I wrote them down in a doc. It’s not a spec, it’s not formal, It’s more a braindump with all the ideas I have for this language: https://hackmd.io/@fcByUhAFQKOgNywKFruHOA/B18qKs59w

[loopingz]

One of the concerns we heard in the past, was resources intensive filtering, it is pretty common on regexp. As you might not have control over who is calling your subscription API we need to find a way to limit its impact