Systems and tools that want to adopt CDEvents may already have a set of events or webhooks defined, which needs to be mapped to CDEvents. It may happen that not all existing events may map to a CDEvent, which raises the question of what to do in those cases.
If the tool supports multiple event formats, it may retain its original messages and add CDEvents as an alternative format, with only a subset of the events supported. Consumers that want to benefit from CDEvents, as well as the extra tool messages, may need to listen to two different channels for both kinds of events.
An alternative solution would be to let CDEvents encapsulate this non-standard data, so that consumers may only listen to one channel to receive the event and use a single SDK to at least extract the event payload and context.
CDEvents allows today for customData to be added to the event's payload. This unfortunately is not enough to fully solve the problem described above. There are two alternative options that could help:
either allow tools to define their own custom CDEvents types, optionally with their own schemas, and let CDEvents SDK marshal and unmarshal such events
or introduce a CDEvent generic/encapsulating event, and let tools send and consume any non-standard event through it. This second option means that no unexpected event type needs to be accepted by the SDKs, and the details about the type and optionally schema would have to be hosted in the customData, making it impossible for the CDEvents SDK to validate the payload
While custom types or generic events may be counterproductive in terms of standardisation, they may be very beneficial during the initial adoption phases of CDEvents.
afrittoli
commented
8 months ago
Systems and tools that want to adopt CDEvents may already have a set of events or webhooks defined, which needs to be mapped to CDEvents. It may happen that not all existing events may map to a CDEvent, which raises the question of what to do in those cases.
If the tool supports multiple event formats, it may retain its original messages and add CDEvents as an alternative format, with only a subset of the events supported. Consumers that want to benefit from CDEvents, as well as the extra tool messages, may need to listen to two different channels for both kinds of events.
An alternative solution would be to let CDEvents encapsulate this non-standard data, so that consumers may only listen to one channel to receive the event and use a single SDK to at least extract the event payload and context.
CDEvents allows today for
customDatato be added to the event's payload. This unfortunately is not enough to fully solve the problem described above. There are two alternative options that could help:customData, making it impossible for the CDEvents SDK to validate the payloadWhile custom types or generic events may be counterproductive in terms of standardisation, they may be very beneficial during the initial adoption phases of CDEvents.