Hi Benjamin,
some belated answers to your points
On 10/29/2015 05:29 PM, Benjamin Cabé
wrote:
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?
I think you are right to be concerned. These are exactly the
complications which were thought best avoided by not including
offline buffering in the first place, and leaving that to the
application. However we do have a lot of requests for the feature.
We could achieve these aims by using a gateway like Kura, or a
broker like Mosquitto to provide the store and forward facilities.
Alternatively we could provide an optional, simple implementation.
We'll send a proposal out before implementing anything, so we can
discuss further and see what makes sense.
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.
Great!
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.
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
Possibly. That's very similar to my Python proxy for testing:
https://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.testing.git/tree/interoperability/mqtt/proxy
Either one would need more configuration options, I guess.
Cheers,
Benjamin
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev
--
Ian Craggs
icraggs@xxxxxxxxxx IBM United Kingdom
Paho Project Lead; Committer on Mosquitto
|
