Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Paho/Project Plan"
(→Directions) |
|||
| Line 19: | Line 19: | ||
* I am assuming the MQTT specification will evolve over the next couple of years. Would it make sense to start an incubator to try out some new ideas | * I am assuming the MQTT specification will evolve over the next couple of years. Would it make sense to start an incubator to try out some new ideas | ||
| − | for the spec? Developers could contribute code that implements these ideas and this would help the MQTT TC in the evolution of the spec. | + | for the spec? Developers could contribute code that implements these ideas and this would help the MQTT TC in the evolution of the spec. (Ian Skerrett) |
| − | * I'd like to see a focus on creating tools to test/debug/deploy MQTT apps. Tools like MQTTLens I think will be critical to the adoption of MQTT. Could Paho be the home to these types of tools | + | * I'd like to see a focus on creating tools to test/debug/deploy MQTT apps. Tools like MQTTLens I think will be critical to the adoption of MQTT. Could Paho be the home to these types of tools? (Ian Skerrett) |
| + | * I think the MQTT embedded security story could be greatly improved (Julien Vermillard) | ||
| + | |||
| + | I think today using MQTT or any M2M protocol with security on any embedded platform is difficult and cumbersome. | ||
| + | |||
| + | I use wakaama with tinydtls a DTLS implementation MIT licensed and at some point I would like to provide ready to install client on some platform but with security (with a business friendly license) as a mandatory feature. | ||
| + | |||
| + | Maybe it worth looking at http://axtls.sourceforge.net/ (BSD licensed) or extending tinydtls for providing good old TLS which is in fact simpler than DTLS. | ||
== Actively Soliciting Contributions for == | == Actively Soliciting Contributions for == | ||
Revision as of 08:36, 26 September 2014
Contents
Current Plan
The release plans are in the project documentation - see "releases" at https://projects.eclipse.org/projects/iot.paho/documentation.
Current and Future Major Items
- .Net client currently being contributed
- MQTT Test Suite under development
- Embedded client libraries for MQTT
- MQTT SN embedded clients and tools
- Android service
- "offline buffering" and automatic reconnect for mainstream clients
Directions
- Expand client library coverage to all major programming languages (http://spectrum.ieee.org/computing/software/top-10-programming-languages)
- I am assuming the MQTT specification will evolve over the next couple of years. Would it make sense to start an incubator to try out some new ideas
for the spec? Developers could contribute code that implements these ideas and this would help the MQTT TC in the evolution of the spec. (Ian Skerrett)
- I'd like to see a focus on creating tools to test/debug/deploy MQTT apps. Tools like MQTTLens I think will be critical to the adoption of MQTT. Could Paho be the home to these types of tools? (Ian Skerrett)
- I think the MQTT embedded security story could be greatly improved (Julien Vermillard)
I think today using MQTT or any M2M protocol with security on any embedded platform is difficult and cumbersome.
I use wakaama with tinydtls a DTLS implementation MIT licensed and at some point I would like to provide ready to install client on some platform but with security (with a business friendly license) as a mandatory feature.
Maybe it worth looking at http://axtls.sourceforge.net/ (BSD licensed) or extending tinydtls for providing good old TLS which is in fact simpler than DTLS.
Actively Soliciting Contributions for
- PHP client
- Ruby client
- Node.js client