Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Each library supports the full MQTT 3.1 specification including:
- QoS 0, 1 and 2
- payloads up to 256MB (MQTT server support needed)
- will messages.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
Each of the APIs in any of the languages has a similar look and feel, with one operation for each of the MQTT commands, connect, subscribe, unsubscribe, publish and disconnect. So, the behaviour of each is similar, internally.
Static analyis of the C client library showed only 3 possible logic errors, none of which were serious.
Gerrit is used to review contributions on the C, Java and Python repositories. Build and test results are available on the Paho HIPP instance: https://hudson.eclipse.org/paho/, with builds triggered automatically by Gerrit submissions for the Java and C repositories.
The C client library does make use of OpenSSL for secure connections. However OpenSSL is not packaged or supplied with the Paho library - the version of OpenSSL provided by the host operating system is used. So it is up to the user to use a version of OpenSSL which they are happy with. The Python MQTT client library also indirectly uses OpenSSL through the Python SSL libraries. Python itself needs to be kept updated to get the latest OpenSSL fixes.
One issue was raised as a vulnerability (https://bugs.eclipse.org/bugs/show_bug.cgi?id=425195), but this is normally avoided as described in the bug. An option to allow this will be added in a future release.
A number of MQTT/Paho articles have been written and linked to from the website: http://www.infoq.com/articles/practical-mqtt-with-paho, http://www.eclipse.org/paho/new/articles/talkingsmall/.
All of the APIs have samples to show how to get started with the API and reference documentation in a form suitable for that language (JavaDoc, Doxygen, etc).
Each of the APIs in any of the languages has a similar look and feel, with one operation for each of the MQTT commands, connect, subscribe, unsubscribe, publish and disconnect. The success or failure of these operations is reported either synchronously via a return code, or asynchronously in a callback, depending on the API. The basic styles of API have been developed over 8 years or more, from before Paho's existence, and continued within Paho, so we are confident of their basic usability. We continue to get feedback and improve where necessary, for instance with the new embedded APIs.
No previous releases, so this does not apply.
The current support is for the MQTT 3.1 specification, here: http://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html
Future releases will also support the OASIS MQTT 3.1.1 standard, which has not yet been finalized.
and 30 unresolved: https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_sta....
At EclipseCon, an MQTT interoperability test day was held (http://eclipse.org/org/press-release/20140407_mqtt_test_day.php). Test material from Paho was integral to the success of this day - although the test material is not part of this release. Four sessions at EclipseCon referenced MQTT and Paho: "Flying Sharks and M2M", "M2M Lightning Talks", "M2M, IOT, Device Management", "Powering Your Next Internet of Things App with MQTT".
MQTT.org is a central focus of the MQTT community - Paho news is updated here too http://mqtt.org/tag/paho.
A formal release for Paho is an integral part of raising its profile.
We are working with the mbed (mbed.org) community on embedded MQTT clients: http://mbed.org/teams/mqtt/
Several Paho committers are part of the MQTT standardization committee at OASIS: https://www.oasis-open.org/committees/membership.php?wg_abbrev=mqtt
MQTT and the Python client library: https://speakerdeck.com/jpmens/mqtt-for-sysadmins