| Re: [mosquitto-dev] libmosquitto outgoing queue request for comment |
My quick reaction is that this is jumping to a very complicated approach and skipping over intermediate ones that are likely to be sufficient for most cases. I'm really unclear on when people decide to use qos 0/1/2 and why, because there are dreadfully few protocol specs published (at least that I have seen) that define the actual protocol used for communication over MQTT. Overall, I would lean to having queuing be optional, with configurable limit on # of queued messages (default 128?) configurable if a publish on a topic will replace the previous stored-and-not-yet-sent message on that same topic Here, the big question is if there's a desire for every message to be delivered, perhaps because it has json with a time and a value, or if only the latest is useful, because it's just a value. That then leads to questions about choice of qos and persisting mesages to stable storage so that they can survive not only broker disconnect but also local reboot or power loss, and by the time you are done then perhaps you should instead construct a reliable transfer protocol that uses MQTT like UDP. So to evaluate your proposal I'd like pointers to protocol specs of "send this data via MQTT". (It is both a plus and a minus of MQTT that you can sort of get away with not defining that.)
Attachment:
signature.asc
Description: PGP signature