First pass at an 'extension attributes' doc#126
Conversation
Signed-off-by: Doug Davis <dug@us.ibm.com>
|
@duglin I'd love to see an endorsed Use case is that a piece of middleware might accept a CloudEvent only if the publisher is authenticatd in some way, such as an HTTP Authorization header. The middleware might not want to pass the header along but may want to pass some context around the user or publisher that sent the event. Could be a very useful area to have some standardization. |
|
@alexdebrie feel free to open a PR for the group to consider it. I'm hoping this PR can get merged tomorrow (hint hint looking for some LGTMs!), then it provides the placeholder for PRs like yours. |
|
@alexdebrie I had proposed something similar in the past, though I retracted it until I could have some time to finalize what we would use within Google. Would definitely love to chat if you have opinions/desires for what these extensions would contain. |
|
This LGTM. I'd like some additional ideas about how an extension should be graduated into a normal property. Ideally an Event Source isn't required to double-publish the data as an extension and normal property. Maybe they just support both but decide which field to use based on the |
|
Approved on 3/29 call |
3 participants
There is a strong desire by the WG to keep the list of attributes we include in the specification down to the minimum necessary to achieve our goals. However, there have been some attributes proposed that seem to be popular in some usecases, but just not enough usecases to cross the threshold of being included in the spec as formal attributes. We've talked about possibly having a spot to put those attributes so they can be used as extensions - then at least there's the possibility of some amount of interop around them even if they have no official standing from our WG.
To that end, this PR proposes a starting doc to host some extensions that people can use.
Signed-off-by: Doug Davis dug@us.ibm.com