[Event Framework] Is the distinction between Event and EventPayload needed?

[janpmeyer]

This is the discussion following started in the PR #1915.

The question was arised, if the current structure of Payloads contained in the Event Classes are needed or not.

So the question is now. Are we gonna stay at the current state of the Event Structure or are we doing a change on it? (@ndr-brt , @jimmarino)

[ndr-brt]

They were separated to permit in the serialization phase to have a distinct payload field containing only the event-specific data keeping it separated from the common-event metadata (id, at, type...).
Nothing is really needed, but in my opinion this division helps to keeps thing tidy, however I'm not against collapsing them in the same hierarchy if that brings advantages

[jimmarino]

Sure, let's discuss, I think it will simplify a number of things. Currently, there are two hierarchies formed and a lot of extra classes that cut be cut from the codebase.

[janpmeyer]

I personally think that if we add much more information to the payload it could be really helpful to seperate both. But right now the Payload is carrying just one ID and for the rest of the information you need to use the different storages.

So one way is to add much more Information in the payload, so you dont have to request in many cases the storages.

Or we lose the "overhead" strucure and just combine both classes. But i dont know what consequences are created with this change.

Mabey at some point we rethink the current Event Framework at all and then are making this change if we create a complete new Framework.

For example i think the mechanism of filtering the Events is mabey to expensive on side of computation time.
If we use in a next version of the Event Framework a solution, where Extension can subscribe more concrete Events we could improve the Event Framework. But this is i think a topic for the future.

[ndr-brt]

For example i think the mechanism of filtering the Events is mabey to expensive on side of computation time. If we use in a next version of the Event Framework a solution, where Extension can subscribe more concrete Events we could improve the Event Framework. But this is i think a topic for the future.

I would avoid to talk about performances without any data that demonstrates this.

I agree on adding meaningful information to the events, this was foreseen at first, but nobody had have the need so far.