-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Closed
Labels
ClientThis issue points to a problem in the data-plane of the library.This issue points to a problem in the data-plane of the library.Event GridMessagingMessaging crewMessaging crew
Milestone
Description
Again, I'm not saying the current prototype is incorrect, but writting this issue so I'm sure we address the spec explicitly.
Cloud Event is an abstraction of what is an event: https://github.com/cloudevents/spec/blob/v1.0/spec.md
As so, our CloudEvent class should not assume any serialization of a CloudEvent concept, and model the concept without thinking about the serialization. This implies:
- There should be no
data_base64attribute, but helpers to set bytes correctly - Extensions should be treated as explicit extensions (and not simple new attributes at the base level).
Example:
c = CloudEvent(
id=12,
source='MyApp',
type='CreateStuff'
) # specversion is set by default to "1.0"
c.subject = "mynewfile.jpg" # I could have set it as kwargs, but for the sake of sample
# Set data. API here could be discuss, we could use `data` property setter for instance
c.set_bytes_data(b"PDF%...", "application/pdf")
# Extensions are allowed aside, to avoid collision
c.extensions["reasonCode"] = 204
c.model # Returns the deserialized modelA JSON serialization of this would be:
{
"id": 12,
"source": "MyApp",
"type": "CreateStuff",
"subject": "mynewfile.jpg",
"datacontenttype": "application/pdf",
"data_base64": "ABCDEF_BASE64_OF_PDF",
"reasonCode": 204
}While a binary mode serialization would be HTTP request
ce-id: 12
ce-source
ce-source: MyApp
ce-type: CreateStuff
ce-subject: mynewfile.jpg
ce-datacontenttype: application/pdf
ce-reasonCode: 204
PDF%...
Metadata
Metadata
Assignees
Labels
ClientThis issue points to a problem in the data-plane of the library.This issue points to a problem in the data-plane of the library.Event GridMessagingMessaging crewMessaging crew