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.
This release is focused on
- improving existing features and performance
- introducing support for tenant specific confguration
- initial support for sending commands and control messages to devices.
Command & Control functionality will be available for connected devices only, i.e. it will only be possible to send a command to a device if it is connected at the time of issuing the command.
We have reduced a lot of technical dept in this release around code duplication, unnecessary JSON serialization/deserialization and JavaDoc quality. The initial version of the command & control support has not been tested much in real world scenarios and is therefore mainly intended as a straw man to shoot arrows at.
The client and core artifacts no longer depend on any Spring framework components which can help reducing the footprint of applications that want to use the Hono client but otherwise do not employ any Spring libraries.
no security issues have been reported nor addressed by this release
We have tried to improve the quality of the user documentation by means of adding information about the new Tenant related functionality as well as missing information about functionality that had already been existing before this release.
We believe that we will need to start versioning the documentation according to the release version soon. For this release, however, we simply have marked the newly introduced Tenant API as being available starting from version 0.6 only.
The HonoClient component which can be used to access Hono's remote APIs now provides a more consistent user experience in that it always fails any futures with the same type of exception that can be introspected to determine the cause of a problem.
The MQTT adapter now also supports shortened versions of the telemetry and event topic names. Devices may use just t instead of telemetry and e instead of event which may help in saving a few bytes per message sent from a device.
Adoption of Hono is still hard to track. We do not have any reports of use cases where Hono is actively used. However, Bosch Software Innovations has started a public beta of their commercial IoT Hub cloud service which is based on Hono. We have also seen new people showing up on GitHub issues and the mailing list.
We are very happy to have Jens Reimann on board as a new committer.
The Hono developers have teamed up with the Eclipse Kapua developers in an effort to allow Kapua to employ Hono as its device connectivity layer. In the context of the IoT Working Group's Integration sub-group, we had an initial face to face meeting where we agreed on the steps necessary for making it happen and have since started to work on the issues required to allow Hono to be integrated with Kapua. Our goal is to demonstrate the integration at ECE 2018.
Hono itself does not provide brokering or routing of messages. For that purpose, Hono employs Apache Qpid Dispatch Router and Apache ActiveMQ Artemis. For cloud scale deployments, Hono relies on the enMasse project which integrates Dispatch Router and Artemis into a cloud based Messaging-as-a-Service solution. We are working closely with the enMasse developers to improve integration and e.g. allow the usage of shared identity management and authorization infrastructure.
Our friends from the Eclipse Ditto project have worked on an integration with Hono by means of an AMQP 1.0 adapter that can be configured to connect to Hono in order to receive telemetry data and events published by connected devices. We are planning to intensify the collaboration and enable Ditto to also support sending updates and commands to devices via this adapter.