Community
Participate
Working Groups
Here is a couple of use cases (copied from email sent by Dennis Wulff) 1. Mobile App publishes messages to back end App Connects App attempts to publish message (wants guaranteed delivery) and is no longer connected App retries without success Now what to do with this message Save it in JS object? Save in indexedDB? Drop and notify user? Currently to guarantee delivery some custom coding is required to save and manage the message until reconnected. It would be ideal if MQTT lib handled storage and resend logic. 2. App is deployed to field on laptop roaming in and out of wifi Same as above
Assigning to Mike. Use cases: 1) Remember we are talking about browser apps only for this JavaScript client. The client could give similar options to the Java or C clients for persistence - allow the app to choose what type of persistence to use: memory, disk, or an app supplied plugin. Disk or similar is only needed if the app can terminate and then restart with those messages ready to send. Given that the current JavaScript application does not persist to anything other than memory, I suggest we do the same for the "offline buffering", for now. That's what many client libraries do anyway. 2) This means the wifi connection is dropping and re-establishing. While the app continues running, you don't need to store the messages in anything other than memory like the Paho Python client.
I think for JavaScript we can have a callback to allow the application to persist offline messages via HTML5 webStorage support https://html.spec.whatwg.org/multipage/webstorage.html
Yes, I was thinking that for HTML5, then using webstorage would be an option. A callback would be an ideal solution. We would also have to add a callback for the persistence of inflight message state, which doesn't exist at the moment.
Migrated to GitHub Issue: https://github.com/eclipse/paho.mqtt.javascript/issues/6
