Nested events?

[cloudevents]

Nested events?

[cathyhongzhang]

This is related to the question I raised in last week's meeting. For this case, is the SaaS application the event source or API GW the event source? If API GW is the event source, event data from SaaS Application should be the payload of the API GW event (the Alternative 1) and some metadata needs to be added to the API GW event metadata fields so that the event consumer knows how to extract needed info from the SaaS data.

[duglin]

With the HTTP/JSON structured format, where the content type is "application/cloudevents+json", I would think that a nested CE would have its CE contentType property set to "app/ce+json" and then data would be the nested CE as json. no? If so, is there anything to formalize in the spec about this or would perhaps adding a sample be sufficient?

[deissnerk]

Yes, that sounds like a good solution. What do you think, @cathyhongzhang ?

[duglin]

Related to #87 ?

[duglin]

@deissnerk what are your thoughts on this one? If an example is sufficient, would you be interested in creating a PR?

[deissnerk]

@duglin I think that the case I brought up, may not be that relevant in practice. The event on the API gateway is probably not worth wrapping into a CloudEvent on its own. Nevertheless there might be cases, when people decide to nest CloudEvents for whatever reason. So having an example makes sense.

I can create a PR with an example outlining the idea you brought up. It might take a few weeks, though.

[duglin]

ok thanks

[duglin]

@deissnerk any update on this one?

[duglin]

@deissnerk can we close this one or do you think we need to add some text in the primer to explain how people could put a CE into the data attribute of an existing CE (if they wanted)?

[deissnerk]

@duglin I was just about to create an example according to your proposal above. It turns out, that this does not work, if you put a nested event inside an event that is sent using http binary mode. Our http protocol binding states:

The receiver of the event can distinguish between the three modes by inspecting the Content-Type header value. If the value is prefixed with the CloudEvents media type application/cloudevents, indicating the use of a known event format, the receiver uses structured mode. If the value is prefixed with application/cloudevents-batch, the receiver uses the batched mode. Otherwise it defaults to binary mode.

By this rule, a receiver will retrieve the inner event only. If you send an outer event in binary mode with content type "application/cloudevents+json", the event context in the http header will be ignored. I just checked this with the go sdk.
Does that mean we should advise people, that nesting is only possible, if you do not mix binary and structured mode?

[duglin]

Just to be clear, we're talking about how this:

Content-Type: application/cloudevents+json
ce-specversion: 1.0
ce-type: myevent
ce-id: 1234-1234-1234
ce-source: example.com

{
  "specversion": "1.0",
  "type": "coolevent",
  "id": "xxxx-xxxx-xxxx",
  "source": "bigco.com",
  "data": { ... }
}

is ambiguous, right?

I wonder if it wouldn't make more sense to change the spec slightly to talk about how checking for ce-specversion HTTP header might be the better choice. The text in there is non-normative :-)

[deissnerk]

@duglin Yes, that's the case I was talking about. I agree, it would be more consistent to adjust the spec as you proposed. I'm just not sure, if that is still possible. Is this not normative?
By the way, there is still the document status:

This document is a working draft.

[duglin]

Well, in general there is normative text in there, but unless I'm missing it I don't see any normative text that mandate how people determine binary vs structured.

I'll PR the "working draft" thing :-)

[deissnerk]

@duglin I see your point. There is no MUST, SHOULD etc. It will nevertheless have an impact on implementations. I only checked the go-sdk so far, but I would expect others distinguish structured and binary the same way.

[duglin]

I agree it would impact implementations, but from a spec perspective I think we could modify the text to talk about using the ce-specversion header instead of Content-Type w/o requiring a version bump.

[duglin]

@deissnerk any update on this one?

[duglin]

This would be the way to do it:

Content-Type: application/json
ce-specversion: 1.0
ce-type: myevent
ce-id: 1234-1234-1234
ce-source: example.com

{
  "specversion": "1.0",
  "type": "coolevent",
  "id": "xxxx-xxxx-xxxx",
  "source": "bigco.com",
  "data": { ... }
}