Inbound CloudEvents mapper for ditto

[Pranshu-G]

Creating a custom mapper for ditto to map incoming CloudEvents to ditto protocol. CloudEvents is a specification to describe event data in a common way (see here). The mapper will map incoming CloudEvents to ditto protocol.

To do so, we would:

1. Validate incoming payload(to check if it complies with the CloudEvents specification).
2. Specify a mapping specification using existing ditto classes.

To read more

To check out the proposal

[Pranshu-G]

Hi everyone. To make the CloudEvents mapper, I wanted to draft certain specifications for incoming External Message(as to what type of message should the mapper map to Ditto Protocol). For that I wanted to ask the Ditto community in what way would a mapping specification make sense with respect to Ditto. https://github.com/Pranshu-G/CloudEvents-Mapping-Specification/blob/main/Proposed-Specification.md this is an initial document which will be changed. Let me know your thoughts on how you would prefer it to look like. Thank you.

[ctron]

A few ideas:

• I think type should be something more like org.eclipse.ditto.v2
• Maybe it makes sense to use the datacontenttype to indicate it is something ditto specific?
• Maybe it makes sense to check for the dataschema to start with ditto:, like it is already done by the HTTP endpoint: https://www.eclipse.org/ditto/http-api-doc.html#/CloudEvents/post_cloudevents
• I know we discussed this, but I am unsure about putting the topic into the subject field (see below)

Questions

• I don't see how the headers are mapped in general (where does the "correlation ID" come from? where would other headers be stored?)
• How would a "binary" data section be handled? It might happen (and be valid) that a data section comes as binary or text and still is valid JSON. Would that be handled properly?

Depending on where the Ditto headers are stored, I think it might make sense to consider the cloud events only as a wrapper/envelope and not store any ditto information in its structures (outside of data). Meaning that the topic would not go into the subject. That might be a very simple approach to start with, and by evaluating the type field, it would be possible later on to introduce another format which does that differently.

Of course if would also be possible to just copy the cloud events extensions/attributes (header name minus the ce) into the Ditto headers section.

[thjaeckle]

Hi. I would have expected that the datacontenttypeis the IANA registered content type for Ditto Protocol: https://www.eclipse.org/ditto/protocol-specification.html#content-type

And that datawould simply be a Ditto Protocol message. I don't see benefits in defining another structure for the CloudEvent which needs another mapping back to Ditto Protocol.

Headers could of course be another thing where eg the protocol headers are copied over to the Ditto Headers as also @ctron mentioned.

So what is the idea of what the benefit is with the proposed structure instead of using Ditto Protocol?

[ctron]

I would have expected that the datacontenttypeis the IANA registered content type for Ditto Protocol: https://www.eclipse.org/ditto/protocol-specification.html#content-type

Fancy! :grin: … absolutely!

[Pranshu-G]

Hi. I would have expected that the datacontenttypeis the IANA registered content type for Ditto Protocol: https://www.eclipse.org/ditto/protocol-specification.html#content-type

And that datawould simply be a Ditto Protocol message. I don't see benefits in defining another structure for the CloudEvent which needs another mapping back to Ditto Protocol.

That was the initial idea

So what is the idea of what the benefit is with the proposed structure instead of using Ditto Protocol?

Well what I was trying to do was finding a way to maybe use CloudEvent specs more in tandem with the Ditto Protocol. However, it does look like it has no benefit per se so maybe putting a ditto protocol message inside data field is better