BrighterCommand/Brighter

[Feature] For the MQTT provide Cloud Events JSON as an alternative to Brighter's propietary message format

Open

#3617 opened on May 29, 2025

View on GitHub
 (4 comments) (0 reactions) (0 assignees)HTML (1,898 stars) (295 forks)batch import
.NET0 - BacklogV10.Xfeature requesthelp wanted

Description

Is your feature request related to a problem? Please describe. Since we have built a messaging system over MQTT 3.11, we do not have support for CloudEvents, as MQTT 3.11 does not include headers. To use headers, we would need to use MQTT 5. Whilst we have the intent to provide an MQTT 5 transport, the question remains, how to include headers when we are using MQTT 3.11?

Describe the solution you'd like

  • We need to continue supporting our existing format, as we have users of our messaging.
    • Add support for CloudEvents JSON format. This should thus be an option described on Subscription and Publication (i.e., a RedisMessageFormat with Raw and CloudEvents as options).
  • If we use CloudEvents, we use a different creator and publisher than if we use Brighter.

Describe alternatives you've considered We could ignore header values, unless we are using v5, as many clients will not expect to receive events using the structured Cloud Events payload. Even if we support producing cloud events in JSON format, the consumer may still not understand them. In that case, though the producer can stick with raw. It remains helpful to us to support CloudEvents if only for trace propagation, which we will lose if we do not have CloudEvents.

Contributor guide