Re: [paho-dev] Items for Paho Roadmap

[Benjamin Cabé <benjamin@xxxxxxxxxxx>]

Hi Ian,

I agree somewhat on the store and forward support.  On the other hand, many MQTT client libraries seem to allow application to call publish when the client library is not connected, which is basically the same thing (I believe that Roger's Python client is one of them).  So we have quite a few people who have come to expect it, along with automatic reconnect.   I would hope it would not complicate the API -- in fact, it could make it quite a bit simpler, if done the right way.  You might not even need to call connect:

I guess where maybe I’m (wrongfully?) worried is that I am not sure that an offline client really is just quite as simple as “publish as usual”. If I’m publishing data every second, and the network goes down for 10 minutes or so, I will start piling up a significant number of messages. I may just fill the offline buffer, so what happens next? Can I still queue a “top priority” alert message in my buffer? Will the client automatically discard a less important temperature message?

My fear is that adding offline mode in the “core” client itself will lead to people asking for more features along the lines of the one I just mentioned, don’t you think? Or if the answer is: “well no, we just allow you to call publish when the client library is not connected, that’s all!” then how one is supposed to really leverage Paho’s built-in offline mode should they want to build more complex offline buffering scenarios? Will the be an API to remove a “PendingMessage” from the cache, and things like that?

As it happens,  James has been working on the Android sample app, and it was our intention to get it on the Play store.  I wasn't sure whether Eclipse had any rules about that?  I'll ask James to share what he has done for the app as soon as he can, so he can get other suggestions.

I think that’s perfectly fine for the Eclipse Paho team to put a sample app on the Play Store. Just like Paho-Python is e.g. promoted on the Python Package Index, etc.

MQTT forwarder -- actually I came across a good use case today.  Similar to an MQTT-SN transparent gateway, to enable a device which may not have the capabilities to connect to a wider MQTT service: DNS, TLS or whatever.  The forwarder would take the incoming packets and pass them on to the "distant" MQTT server, so that each device has a separate connection to the server.   Kura certainly can have a part to play, it can certainly do some of the job -- I've just started experimenting with it properly to see what it can do.

Something along the lines of this MQTT proxy from Julien? http://github.com/jvermillard/moxy

10:28 $ moxy --help

Moxy: a MQTT proxy

Usage of moxy:

  -listen string

    the MQTT address and port to listen (default "0.0.0.0:1883")

  -server string

    the target MQTT server to proxify (default "iot.eclipse.org:1883")

  -v dumps verbose debug information

Cheers,

Benjamin