Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Paho/Project Plan"

(moved task list to the top)
(Current and Near Future Major Items)
(32 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Open Task list =
+
= [https://projects.eclipse.org/projects/iot.paho/documentation Current Plan] =
  
* Binary releases of C and Java clients for download
+
The release plans are in the project documentation - see "releases" at https://projects.eclipse.org/projects/iot.paho/documentation.  
* Tutorials for C and Java clients
+
* how to build and use C client on iOS
+
* test suite
+
* protocol compliance suite for reference implementations
+
* update MQTT specification with mqtt.org / mailing list clarifications
+
* Some idea of [[Paho/Repository#Future_needs|potential code additions]] are on the page discussing the Repository structure.
+
  
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Technology&component=MQTT&component=Samples&component=Sandbox&list_id=3090526&product=Paho&query_format=advanced&order=bug_status%2Cpriority%2Cbug_severity list of open Paho bugs]
  
= Milestones =
+
== Current and Near Future Major Items ==  
  
The Paho project will target the Eclipse Kepler release (June 26th, 2013) with a 0.9 release under Incubator status, and two intermediate releases in 4Q12 and 1Q13.
+
* .Net client currently being contributed
 +
* MQTT Test Suite under development
 +
* Embedded client libraries for MQTT
 +
* MQTT SN embedded clients and tools
 +
* [https://wiki.eclipse.org/Paho/Android_Service Android service design]
 +
* "offline buffering" and automatic reconnect for mainstream clients
  
== 0.1 Release (4Q12)==
+
=== Actively Soliciting Contributions for ===
This will be an “snapshot” release of the
+
*Lua, C, and Java MQTT clients,
+
*Eclipse client view,
+
* MqGnatt and any additional example code.
+
  
The 0.1 release will be as an “update site” with the primary goal learn and exercise the Eclipse Build/Release process and tools including Tycho
+
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=442878 PHP client]
 +
* [https://bugs.eclipse.org/bugs/show_bug.cgi?id=442877 Ruby client]
 +
* Node.js client
  
== 0.x Release (1Q13)==
+
== Directions ==
*Line items (common to all clients)
+
**Consistent samples/examples for all language clients
+
**Consistent documentation
+
**…
+
*C client line items
+
**…
+
*Eclipse client view line items
+
**…
+
* Java client line items
+
**…
+
*Lua client line items
+
**…
+
*MQTT Protocol conformance tests
+
**Reference implementation test bed (wire capture?)
+
**Tracing tools/integration
+
*Mobile platform support
+
*Sample and Example Code (integrated in IDE where possible)
+
**MqGantt
+
**REST APIs with end to end examples
+
**Basic MQTT exerciser (Eurotech)
+
**Wizards?
+
**New examples tbs
+
**websockets
+
  
== 0.9 Release (2Q13)==
+
* Expand client library coverage to all major programming languages (http://spectrum.ieee.org/computing/software/top-10-programming-languages)
*M2M Package
+
 
 +
* 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)
 +
Add suggestions here  [https://bugs.eclipse.org/bugs/show_bug.cgi?id=442874 Ideas for tools that could be created or adopted to test/debug/deploy MQTT]
 +
 
 +
* 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.

Revision as of 08:51, 26 September 2014

Current Plan

The release plans are in the project documentation - see "releases" at https://projects.eclipse.org/projects/iot.paho/documentation.

Current and Near 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 design
  • "offline buffering" and automatic reconnect for mainstream clients

Actively Soliciting Contributions for

Directions

  • 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)

Add suggestions here Ideas for tools that could be created or adopted to test/debug/deploy MQTT

  • 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.

Back to the top