Address Persistence in Primer

[erikerikson]

Briefly detail the importance and challenges of persistence and the measured approach to addressing it and its requirements within the CloudEvents specification.

Closes #143
Closes #276
Closes #378

Signed-off-by: Erik Erikson erik.erikson@gmail.com

[erikerikson]

Closing #143 with this may be controversial. I can easily accept removing the closure statement for that issue.

[clemensv]

I don't understand the particular concern here. The sender context is commonly evaluated when the event is accepted by an event broker and then events are "persisted" either in a volatile or durable store where they are held either for pull pickup or push delivery.

[erikerikson]

@clemensv recording the results or artifacts of the evaluation of the context is not provided for in the CloudEvent. Examples: creator identity, confidentiality, irrefutability.

Consider event sourcing and particularly the permanent storage of the event for repeated reprocessing. This declares we're not yet solving the problems of persisting the context.

Note that the context can be vital for business logic. Consider an event demanding a transfer of funds from your account to mine. The identity of the creator and their rights are crucial for correctly performing the transfer or detecting an attempt at fraud.

Effectively, this declares that CloudEvent users will have to solve those problems for themselves. Users will have to supply that information in the data field or augment the CloudEvent prior to persistence. This section makes that explicit.

Does this help you understand the concern? If so, perhaps you can identify what helped and I can clarify the text. If not, can you be more specific or detail what part of the narrative seems to break down or fail to communicate a useful purpose?

[duglin]

"you're on your own" is how interpreted the PR :-)

[clemensv]

@erikerikson I might just be puzzled that this needs explaining. I also think your explanation in the comment here is better than the text.

[erikerikson]

I think that we would be (within the context of the primer) not explaining so much as declaring. In particular declaring that persistence concerns are currently out of scope while recognizing they are important and that the community of users may want to solve some of those concerns. If nothing else, the statements may help to reduce the number of annoying contributors like me. ;). I mean... I still would like those things solved for me (I'm lazy, albeit willing to work very hard to be so) but at least with this I can accept that my concerns have been considered rather than being off the radar. For the percentage that don't read the primer, they can be pointed here when they ask for about such things which not only declares the out-of-scope'ness but suggests a productive way to join the community to expend their energy towards a solution (using perhaps standardized mechanisms supported via extensions).
It may be that this PR should just be closed and no or a different remark made. I would accept that opinion of the group.

[duglin]

Approved on 7/11 call