Closed tomkerkhove closed 4 years ago
This is still on v0.1, but since it's an open standard it would be in my opinion a definite required feature for the project.
Would this mean that we would have besides the IEvent
contract, a ICloudEvent
contract with the values of the standard. And that the Event publishing and parsing mechanism should support both?
Maybe a parent interface can be created acting as a Tag Interface for this.
Cloud Events are actually "already" in v0.2 and I've updated the issue.
A ICloudEvent
would be good, but it should be versioned somehow where the namespace is first thing that comes to mind, but not ideal I think.
Would it make sense if we provide different Event Grid publishers based on spec that they want to use? I think it does.
We should support both publishing & parsing cloud events, but we can seperate that in seperate PRs/issues if we want. It's decoupled as pushing in Cloud Events does not mean you have to receive in that format.
If you mean a "Marker Interface" with a "Tag Interface" I would discourage that - https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/interface
If you mean a "Marker Interface" with a "Tag Interface" I would discourage that - https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/interface
Yeah, I know. I always find it weird that the design guidelines for C# discourage this while in F# the same (kind of) is encourged with Discriminated Unions.
When updating the test infrastructure in Azure, the following changes has to be made to the ARM template:
The initial cloud support could be considered done I think.
Actually not yet I think - Can you provide some documentation on this feature please?
Actually not yet I think - Can you provide some documentation on this feature please?
Ah, let me check.
Docs are available on https://eventgrid.arcus-azure.net/features/deserializing-events
Provide support for sending and handling Cloud Events according to the CNCF spec.