Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Plans for MQTT V5 in Paho

Hi all,

Regarding the Java client implementation, it might be interesting to note that the OSGi Alliance is also currently working on an MQTT client API that exploits the latest Java features and runs nicely within an OSGi framework. The current proposal is to have a Java 8 Streams like API that allows to process incoming MQTT messages asynchronously using lambda expressions.

It would be cool if Paho would support the OSGi spec out of the box or at least plays nicely with it. The OSGi spec design is far from complete so any feedback from the Paho community is welcome. The current design document can be found at https://github.com/osgi/design/blob/master/rfcs/rfc0229/RFC0229-MQTT.pdf

Best regards,

Tim Verbelen

On 07/26/2017 01:38 PM, Ian Craggs wrote:
Hello all,

the MQTT version 5.0 specification is nearing completion, with the availability of working draft 15 (https://www.oasis-open.org/committees/documents.php?wg_abbrev=mqtt&show_descriptions=yes), which is going to be, with very minor changes, the first Committee Specification Draft (CSD). This means that we are nearing the end of the process of creating the MQTT 5.0 specification. There is a 30 day review period for the CSD once it's officially published, then if changes are needed as a result of feedback, there will be a second CSD with a further review period, and so on. We anticipate that two CSDs will be sufficient.

To facilitate MQTT v 5.0 adoption and awareness in the community, and give feedback to the OASIS TC within the CSD review period, James Sutton and I are proposing to start work on implementations in Eclipse Paho. The rough plan is:

1) Ian to write a Python "test" broker to enable client testing and a server implementation model.

2) James to start work on a Java client implementation. This will probably be a completely new codebase, because the existing Java client was for a long time deliberately constrained to the Java 1.4.2 language level to be compatible with JavaME. A new code base will enable later Java language features to be fully exploited.

3) Ian to write C and embedded C client implementations. I haven't decided yet whether or how to extend the current codebases or write new ones. My plan is to try extending, and if that proves excessively complex, to review that approach.

4) After Java, James will probably look at JavaScript next.

We will open issues in the relevant projects to encourage discussion of MQTT v5 support.

If any other committers also want to embark or experiment with MQTT v5 support in their components, we of course will welcome that! Your thoughts and comments are of course welcome.

Thanks.



--
Tim Verbelen
Ghent University - imec
IDLab
iGent Tower - Department of Information Technology
Technologiepark-Zwijnaarde 15, B-9052 Ghent, Belgium
T: +32 9 33 14905 ; T Secr: +32 9 33 14900
E: tim.verbelen@xxxxxxxxxxxxxx
W: IDLab.UGent.be ; W: IDLab.technology



Back to the top