Hi Benjamin,
thanks for the comments!
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:
1. create client object
2. publish, subscribe
or connect and disconnect merely indicate that this is the state you
wish the client to gravitate towards. For the Java client, seeing
how we would work with the Kura functionality is another
consideration. Making it work well for the Android client is
really important, though.
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.
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.
Ian
On 10/29/2015 04:39 PM, Benjamin Cabé
wrote:
Hi Ian,
I'm planning to put
together a release roadmap for Paho for the next year to
18 months. Items on the list include:
Hey, that’s a great list! A few comments inline.
- contributing to
M2Mqtt: regression tests, disk persistence, maybe some
other items
- offline buffering
(ability to send while not connected) and automatic
reconnect for C, Java and _javascript_ clients
I am not sure I understand the rationale? To quote Andy Piper
in some early Paho presentations, I see Paho as one of these
tools from the “gnu” toolbox that can be piped into other tools.
If one wants to have store and forward support, I don’t think
that’s the responsibility of the core communication stack?
FWIW, when I want to use say an HTTPClient from Apache
Commons, I don’t expect it to do the cache management for me,
nor do I expect the API to be cluttered with such features. The
HTTP Cache would be another optional component, right?
Or is maybe the intention to make this “offline buffering” a
side/optional component as well? In which case I think we may
already have such a component, in the form of Kura’s MQTT
transport service, no?
- ongoing embedded
client improvements: proper FreeRTOS support, asynchronous
clients, build improvements, documentation: porting
guides, tutorials, formal MQTTClient-C release
- Android service stability - it's possible James has
achieved much of this already, but we'll have to
I think the Android service could perhaps use some love in
terms of promoting a sample application built on top of it. The https://eclipse.org/paho/clients/android/ web
page could probably include some code snippets (just like for
the other flavours), and we could have an official sample Paho
app “a la MQTTlens/MQTT.fx” on the Play store?
- WebSockets support
for C, Python clients (any others?)
- MQTT-SN to MQTT embedded gateway
- MQTT conformance test material
+1. I would be happy to help promote such material.
- possibly an MQTT
forwarder for DMZ (it's been mooted, but I'm not exactly
sure what it means)
Not sure what it means either. I have the impression this is
also an item where you may want to point people at Kura?
- device management in
the form of a LwM2M mapping over MQTT. However,
before we can commit to an implementation plan, the
Eclipse Foundation is working to clarify a few legal
matters with the OMA.
Yup.
Thanks!
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
|