+1 as it is most likely other MQTT Brokers are used in an enterprise grade context.
Additionally, if for some reason some use cases like to shift towards other protocols such as AMQP or Zenoh it is helpful to have it based on the architecture to have a "normal" MQTT or other protocol library. I personally talked about that topic at ASF Community over Code in New Orleans in 2022. -> https://www.apachecon.com/acna2022/slides/01_Ott_From_Leadingedge_Iotprotocols.pdf where I listed additional protocols that could be interesting to be supported. Especially on the edge. Just my five cents. Lukas Am Mo., 29. Apr. 2024 um 14:01 Uhr schrieb Christofer Dutz < christofer.d...@c-ware.de>: > Hi all, > > currently a lot of the plans we have for 2024 (at least my plans) involve > MQTT as one form of transport for data into IoTDB. > > Unfortunately, currently all of IoTDBs MQTT support is built around the > built-in Moquette MQTT broker. > > However, I think it’s totally out of the question, that any larger company > would agree on using this broker as their communication back-bone. > > Therefore, I would propose to refactor IoTDB to be able to use any MQTT > broker as client but to keep Moquette in there, if a user doesn’t have an > MQTT broker available. > > The main change that we would need, would be to refactor the code that > currently integrates into Moquette for processing messages and to rewrite > this to use a normal MQTT client library. > > > What do you others think about this? > > Chris > >
