Filters - Custom Filter Dialect/Custom Protocol

[zZHorizonZz]

We're working on implementing the subscription API, but as we are going trough implementing this on our own as there aren't any language-specific implementations yet, we're a bit hesitant on some things. We're thinking that if language-specific implementations do appear in the future, there might be a problem if someone wants to use their own dialect.

Here's our reasoning: if someone generates their own server based on the OpenAPI specs, it'll generate the models for filters. But if they want to use a custom dialect, like CEL (Common Expression Language) in our case, they'd have to create a custom version of the subscription API specs and potentially provide custom SDKs instead of relying on official SDKs which we can imagine will contain the client or at least client abstraction for communication with subscription API.

We had similar thoughts about sink protocols. There's no way to provide a custom protocol right now. For example, if we wanted to use gRPC (with its own HTTP/2 protocol), we'd have to propose it and wait for it to be added to the official specification.

While we understand that the API specs aim to unify things, we think that implementors/providers should be able to decide on and provide their own filters and protocols.

I think for optional dialects there could be something like:

{ 
  "custom": {
    "type": "sql (Or any other dialect)"
    "expression": "source LIKE '%cloudevents%'"
  }
}