Hi,
Sorry if I wasn’t clear: my point is that yes it’s something that MQTT/Paho users do need and this feature probably belongs to Paho. I didn’t want to imply that people who want tore and forward have to be directed at Kura, I rather meant: the feature is already there in Kura, so I do want to make sure that – to quote you, Dominik – Paho does not reinvent a wheel we already have at Eclipse and that I think has been tested in lots of different scenarios already (both from an API point of view, and from an implementation point of view).
So it would be great to see if the Paho and Kura team could evaluate if that’s something that makes sense. I guess my hope is that the bundles relevant to offline mode in Kura get moved to Paho and become that paho-offline.jar module that one would add to its app to benefit from the offline mode capabilities.
Does that make sense? Benjamin –
Benjamin,
Offline Buffering for Paho is the single most important “feature request" I heard from people using MQTT and Paho. While I personally agree with you, I’m under the impression that many people are annoyed that they have to write such a basic functionality by their own. So I would love to see at least a higher level API or wrapper for Paho which comes with such a functionality. Doing offline buffering right - with disk persistence - in a performant fashion is harder to implement than it seems at first, especially with QoS guarantees. So I would absolutely love to see that feature in Paho so people can stop reinventing the wheel.
While the offline buffering fits perfectly to Kura, most Java MQTT applications I have seen until now use Paho directly instead of Kura, especially if they’re not a Gateway software :) Just for the sake of adding offline buffering to the application, IMHO it would be overkill to add Kura to the mix for many projects if Paho is already in place.
All the best, Dominik On 29 Oct 2015 at 17:40:18, Benjamin Cabé (benjamin@xxxxxxxxxxx) 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
|
