Potential ideas around how to transition from customData to CDEvents data

[xibz]

We discussed this at the WG, but I wanted to add an issue here, or somewhere more appropriate but this seemed like the best place, but could be an issue in each of the SDKs?

Right now if a field that is needed by some field is needed by a consumer, a producer has to add that to the customData section. While this makes CDEvents flexible for fields the spec does not have, it does not illustrate a good story on how to move from customData to CDEvents, if that field makes it way to subject or context portion of CDEvents.

A few ideas that had came up from the WG is potentially have adapters/helpers/hooks to do this within the SDKs. In Go, there is something called go tags that is struct like metadata which is generally used in: marshaling, validation, default value, etc.

Here's an approach that might work for the Go SDK:

type MyCustomEvent struct {
    cloudevent.CDEvent // embed the CDEvent struct
    MyField string `cdevents:customdata.myfield`
}

So the idea here is there'd be custom serializer/deserializer that handles all that. Let's now assume MyField get's added later in CDEvents, users would just need to delete the MyField field and it'd keep working. This is just an idea, but definitely want to open this up for discussion

[e-backmark-ericsson]

I might misunderstand the intention here, but is the intention to provide some specific customData fields through the SDK that is not (yet) defined as valid parameters in the CDEvents spec? I think the SDKs should be generic enough for any customData to be added by its users. No SDK should declare any specific data fields that end up in the customData section of a CDEvent.

[xibz]

No SDK should declare any specific data fields

Except if your company decides on what custom data looks like. SDKs should be able to provide that if needed.

that is not (yet) defined as valid parameters in the CDEvents spec

Correct. How do you easily transitions services from using customData to the new version?

[e-backmark-ericsson]

Except if your company decides on what custom data looks like. SDKs should be able to provide that if needed.

I see two options for expanding/detailing the SDKs for custom needs by a certain user of CDEvents. Either by providing the SDK as an expandable library, eg. making it possible to sub-class. Or by recommending the users to create custom schemas which the SDKs could validate the generated event towards. This latter option would require a schemaUri parameter in the core event spec, as proposed in #91. The last bullet in that issue mentions the need for custom schemas/validations.

[e-backmark-ericsson]

Correct. How do you easily transitions services from using customData to the new version?

If an organization requires certain fields in the customData object which are later added as a supported field in the CDEvents standard, the event consumers in that organization needs to be able to interpret both the original customData field and the new standardized field until all producers are updated to the new spec version.

If the organization uses custom event schemas (as described in my previous comment), the next version of those custom schemas should not include the old customData field anymore, forcing the event producers to abide to the new standard when using a newer schema version.