Serialize and deserialize custom extensions

[gradybarrett]

Is your feature request related to a problem? Please describe.

I work in a large enterprise, and we have a few custom extensions defined. With the given structure, we can just extend the CloudEventV1 interface, add our extensions, hand that to devs, and they can just create CloudEvent's with that options interface. Super lightweight. Awesome. 🥳

What I don't love is that there's no clean way to inject our custom extensions into the transport layer, specifically for deserialize.

For example, we define a tags extension, which is simply a [key: string]: string object, that we encode. Easy to kinda handle for serialize via a toJSON() implementation. But for deserialize (and proper serialize support - binary + structured) to decode tags, we're going to have to, for example, wrap the HTTP deserialize function, then provide our own Binding for HTTP and have folks use that custom binding. Doable, but I don't love having to wrap the existing functions and then maintain our own Bindings, all for each transport.

Describe the solution you would like to see

It would be cool to be able to define an Extension, something like this, patterned after the Binding interface:

interface Extension {
  // CE Extension's key/name
  key: string;
  deserialize: ExtensionDeserializer;
  serializeStructured: ExtensionSerializer;
  serializeBinary: ExtensionSerializer;
}

Then be able to "register" those extensions with the transport code, then have the transport code exec the correct supplied extension code when it sees an extension key that matches a "registered" extension.

I realize the interface above is a bit naive. We'd want a way to be able to implement that interface per-transport type, but hopefully that's enough for you to kinda see where I'm headed with this.

Is that sort of interface something you would entertain?

[duglin]

Ping @lance

[gradybarrett]

Adding to this thread since we've had have more conversations since. We'll also want to talk through how to handle multi-attribute extentions such as tracing and data classification. The Java SDK implements, for example, data classification as a single extension with multiple keys, then serializes that extension into multiple attributes on the cloud event. That leads to the existing readFrom and keySet interface. Not sure I'm a huge fan of how that was done, but I get why it was done.