IoT SIG - 2021-10-13

MattJ So far, I don't even *want* to use MQTT :-) However, somebody asked "Can I use your XMPP PubSub based data thingy with MQTT, please?" and I try to get them used to XMPP first. Still, it is good, if I know beforehand, if there is any solution in case they remain stubborn.

But thanks for your offer - let's hope there is no need to actually try!

Just FYI: While Ejabberd does support MQTT, it is completely separated from the XMPP world. Bridging or mixing the two protocols is not possible.

Huh, surprising

MattJ Yes, because that would make it interesting to use it for MQTT. If I need pure MQTT, I probably use a pure MQTT server. But maybe bridging is planned for the future, who knows.

crazy that the MQTT stuff is in ejabberd then

might as well run another stand alone MQTT server

looks like prosody has the better feature set in this regard

not that I aim to improve the ejabberd situation by starting some competition in this regard with this comment ;)

:)

I don't know how I feel now about the conversation I had when their blog post announced this ability

https://news.ycombinator.com/item?id=17958305

The conversation focused on the fact that they didn't do it first, but now it seems they didn't do it at all :P

I'm sure there is value in a massively scalable MQTT server written in Erlang, but without bridging between the two I don't know what the advantage is or why you'd call it a "dual-protocol" (to me that strongly implies two protocols to access the same data)

*what the advantage is to building it into ejabberd

I assume there is some code re-use