spec
spec copied to clipboard
cloudevents
SDKs should bubble-up non-CE data too - like extensions
iiuc this issue title — the PHP SDK provides access to extensions directly on the CloudEvent object. It also enforces validation via the setters around the spec's requirements.
In what way are extensions "non-CE" data? I'm confused about the question. Happy to answer it when I understand it :)
Pretty sure this is asking to expose the CE-xxx attributes in the message that are not defined by the spec. However, I also want to say that it also includes providing a way to get the non CE-xxx attributes too (like other http headers) - but I could be wrong.
Right - the title made me think it's about genuinely non-CloudEvent data that happens to be in the same message. We definitely don't expose that in C#... if you want to get at non-CE headers from an HTTP request, get 'em yourself :)
I think ideally we'd like a SDK to take an event from a given transport and give you a full event object in your language's type. We don't want to expose working of the transport, like all HTTP headers.
We probably only want to expose the standard context attributes (like ce.id) and documented extensions (like ce.traceparent). If a user wants to grab an undocumented, unrecognized attribute, the SDK probably shouldn't limit a user from adding the attribute to the CE, but the SDK shouldn't bubble up non-standardized data.
The Ruby SDK supports both spec and extension attributes. It will decode any attribute with any name on an incoming event (e.g. all CE-xxx headers). For event objects in memory, it will let you set an attribute with any name, recognized/documented or not, and it includes all attributes, recognized or not, when encoding an event. However, it performs validation and type conversion only for attributes in the core spec. Extension attributes are always strings.
Agreed that non-CE headers are out of scope. If an application wants them, it needs to handle them separately from the SDK.
To be clear... are people exposing ce-foo to the SDK users, but not foo http header. Right?
For C#: Yes, but not as "a ce-foo header" but as a "foo" extension attribute.
One thing we've done in the Go SDK in the STAN protocol is copy protocol-specific information onto the context.Context via a decorator/middleware pattern. It's also opt-in for the SDK users so didn't break any default behaviour. This way, if you knew you were using STAN you could access extra information like re-delivery count and the message sequence number.
https://github.com/cloudevents/sdk-go/issues/657
I'm not sure if all SDKs have functionality similar to Golang's context.Context and middlewares to support customising them, but within the Go SDK you could implement similar logic to attach the original HTTP headers to context, and similarly for any other protocol etc.
In the JavaScript SDK, the behavior is essentially the same as in Ruby. We do not validate non-spec extensions, and the type can be anything, but in practice it's typically a string - because most usage is with binary encoding, and so these values will be a string in the header.
In the PowerShell SDK the behavior is the same as in the C# SDK. The exntesion attributes are available without the 'ce-' prefix.
