[WIP] Allow POJOs as CloudEvent data, round 2

[slinkydeveloper]

Fix #196 and follow up from discussions in #198

In this second iteration I've created a new CloudEvent interface in core that extends the one in api. This interface adds getRawData() This interface is used mostly everywhere in core and that's what the user of the sdk should use too (leaving the one in api mostly for integration needs), but always paying attention to support the parent CloudEvent when possible.

As in #198, I had to change the reader/writer interface and I added EventDataCodec but only with serialization support, deserialization of data is out of the scope of this PR (and of this project too)

Signed-off-by: Francesco Guardiani francescoguard@gmail.com

[olegz]

The #198 has suggested a couple of approaches of adding additional functionality to core strategies - approaches that are intuitive and widely used in many java frameworks. So I am not sure why do keep on insisting doing something completely different. . .??

At the very least, please, please, please, don't call it CloudEvent. Aside form it being an anti-pattern, it will create a tremendous confusion and a guaranteed CCEs when developers declare Something<CloudEvent>.

[slinkydeveloper]

The #198 has suggested a couple of approaches of adding additional functionality to core strategies - approaches that are intuitive and widely used in many java frameworks. So I am not sure why do keep on insisting doing something completely different. . .??

You're free to contribute with a PR, in order to propose a solution that you think might fit the needs discussed in #196 and #198

[olegz]

My comments were simply meant to address the issues I see with the current PR, but I certainly appreciate the invitation to collaborate. . .

As suggested in #198, by several people, all you need to do is define additional method(s) on BaseCloudEvent (e.g., BaseCloudEvent.getRawData()) or some other specialized implementation within core module.

Basically remove CloudEvent interface from the core and add getRawData() method on BaseCloudEvent implementation.
OR
Rename CloudEvent in core to something else to avoid name-space/type collision issues.

In it's current state my vote (if counts) is -1

[slinkydeveloper]

I think we still need a new interface for that if a 3rd party implementer wants to use the features of core, and actually no name is better than CloudEvent. The only viable alternative (which doesn't make worse the usage of the sdk) is to relax getData() of the original interface in returning Object, I think that's the compromise where everybody of us is happy. If you don't want to implement any serialization feature, it's perfectly fine, you always return byte[] (and subclassing, you can strength the return value of getData())

[bsideup]

and actually no name is better than CloudEvent

• TypedCloudEvent?
• CarrierCloudEvent?
• POJOCloudEvent?

I am sure there are 10s of other suitable names, but naming it CloudEvent in core while there is one in api is a terrible idea.
Anyone who worked with Java long enough remembers confusing List and List or Date and Date (I let the reader to figure out the package names ;))

Since the need for this interface is questionable anyways, let's at least not repeat the same mistake with clashing names.

[slinkydeveloper]

None of the names you discuss really makes sense IMO, because the CloudEvent as entity is always the same and the fact that there is a new interface to explicit the idea of having the data field as Object it's unnatural: the payload of a cloudevent is dynamic by nature, to the cloudevent user (not the java user) TypedCloudEvent doesn't really makes sense, what is typed? the payload? how is typed?

Hence my proposal in #211, relax the getData() and we solve the issue once and for all

[bsideup]

@slinkydeveloper

a new interface to explicit the idea of having the data field as Object it's unnatural: the payload of a cloudevent is dynamic by nature

You should not forget that you're dealing with Java, where certain restrictions apply that you have to deal with.

TypedCloudEvent doesn't really makes sense, what is typed? the payload? how is typed?

If not the payload, what else can be typed? The whole CloudEvent thing is around the payload, with some extra attributes/extensions that help understanding the payload better. If you think about it this way, it is much easier to reason about the naming and what TypedCloudEvent represents.

[olegz]

One naming pattern that could serve as viable compromise and the one that is widely used is *Aware. In Spring we use it in many places (i can share examples if needed). For example TypeAwareCloudEvent or RawDataAwareCloudEvent

[slinkydeveloper]

Replaced by #250