fix(protobuf)!: Expose CloudEvent structure with explicit fields #1354
Conversation
yordis
force-pushed
the
yordis/protobuffer-message-format
branch
from
4c5050b to
c62b56a
Compare
yordis
changed the title
Previously, all optional CloudEvent attributes were hidden within a generic map structure alongside extension attributes. Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
yordis
force-pushed
the
yordis/protobuffer-message-format
branch
from
c62b56a to
5226604
Compare
| @@ -2,7 +2,8 @@ | |||
| * CloudEvent Protobuf Format | |||
| * | |||
| * - Required context attributes are explicitly represented. | |||
| * - Optional and Extension context attributes are carried in a map structure. | |||
| * - Optional context attributes are explicitly represented. | |||
| * - Extension context attributes are carried in a map structure. | |||
There was a problem hiding this comment.
One of the things that CE has really pushed hard for is the idea that spec-defined attributes and extensions should be treated (and serialized) the same way. The idea of "extension buckets" is something we've avoided.
So, when I see the above text it makes me nervous. Could this be why it was done this way originally?
If, in the future, some extension becomes an OPTIONAL spec-defined attribute, what would change in the protobuf stuff? Ideally nothing, but I suspect with this PR that's not the case. Now, some formats may force us to violate our goal, and I know nothing about protobuf, but I wanted to mention this as we discuss this PR.
There was a problem hiding this comment.
Most likely that was the intent, if such extension becomes part of the schema, you would need such schema version to understand the new message-level field
Previously, all optional CloudEvent attributes were hidden within a generic
map structure alongside extension attributes.
Signed-off-by: Yordis Prieto yordis.prieto@gmail.com