make extensions follow the same pattern as normal attrs #505
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I very much like the idea of limiting the scope to I'll let the transport experts review this tho. |
Signed-off-by: Doug Davis <dug@us.ibm.com>
duglin
changed the title
|
ok - I updated all of the docs that I think need to be updated. |
|
This is good. Why are you asking for the datacontenttype info to flow double for MQTT5, though? That protocol version should work just like HTTP. |
duglin
changed the title
|
LGTM |
duglin
force-pushed
the
issue498
branch
2 times, most recently
from
16b4641 to
5e0e70b
Compare
deissnerk
reviewed
Sep 19, 2019
spec.md
Outdated
| @@ -419,13 +421,31 @@ extensions that might be of interest. | |||
| Each specification that defines how to serialize a CloudEvent will define how | |||
| extension attributes will appear. | |||
|
|
|||
| Extensions attribtue MUST be serialized using the same general pattern as all | |||
There was a problem hiding this comment.
s/Extensions attribtue/Extension attributes
Signed-off-by: Doug Davis <dug@us.ibm.com>
|
Approved on the 9/19 call. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #498
This PR makes CE extensions follow the same rules as all other CE attributes. Meaning:
1 - they MUST be serialized with
ce-prefixes in transports like binary-http2 - they MAY have a secondary serialization, but they MUST still have the
ce-prefixed one too.3 - if they do, and the values differ, then the
ce-version is the CE attribute. The other one, if picked-up by the middleware, is 'some other' metadata that it's passing along.This means that a CE receiver no longer needs to look any place except in one location for ALL CloudEvents data. This also means that ALL CloudEvents extensions will be picked up by ALL receivers. W/o this PR, it's possible for someone to define a CE extension that maps to an existing HTTP header (like
datacontenttypedoes) and because the HTTP header it maps to is a well-known HTTP header, the CE receiver might not realize it's a CE extension and not pass it along to the app. This PR avoids that problem.In the end, this PR gets us back to our "first principles" that CloudEvents is trying to standardize the location of a well-defined set of metadata - even if it ends up duplicating the data. For example, we've talked about how some of our data would be duplicated from the "business logic"(
data) and that's ok. So, let's do the same for extensions too. By allowing some attributes (CE defined or extensions) to ONLY have a different serialization (and possibly location), we're violating our own stated goal. But, allowing for a "secondary" serialization allows for us to have a single location for all CE data but then also allow for existing metadata defined by other specs to still be properly filled-in.Signed-off-by: Doug Davis dug@us.ibm.com