Francesco Guardiani

@dsyer I have a super noob spring question here: why do we need this? We already implement serializers and deserializers for Kafka: https://github.com/cloudevents/sdk-java/tree/master/kafka. Isn't Spring using the Kafka `Serializer`/`Deserializer` interfaces...

> but Spring is more flexible with listener method signatures so you won't get the full benefit @dsyer I see your point, but IMHO this is not a good reason,...

> Yes, probably, but then you'd have to build the knowledge of Kafka header name conventions into the converters we already have (and they so far didn't need to know...

> Isn't cloudevents-kafka already basically a "single encoder/decoder for each transport"? It is, but my understanding of the reasoning behind `cloudevents-spring` was to originally implement just the `Message` encoder/decoder to...

> I would love to use one CloudEventMessageConverter for everything, but it would have to know about all the transports would it not? Yes, but you don't need to know...

This is interesting, do you want to work on this?

Go ahead! I think we want to use actix-web for the protocol binding https://actix.rs/docs/websockets/, so you can just modify the `cloudevents-sdk-actix-web` crate adding the new stuff in there. A first...

@nguyenquannnn I think, for now, just the text format is fine, since this sdk just supports json conversion

@cardil the golang implementation was done before the latest changes to the specification. The goal of the extension is not to carry the actual tracing informations (aka the actual traceparent),...

I marked this as 0.4, hopefully paho.mqtt new version will be released before our new version and we can get this one in. I'll review this PR asap