I agree that the place for something like this would have to start off as being the wiki - primarily because I don't have time to go through the list on the Software page to try to test everything. We've got the start for such a page for server implementations http://mqtt.org/wiki/doku.php/server_support - that needs a lot of expansion.
I think the client version would need to show which levels of QoS are supported, whether MQTT v3.1 authentication is supported, the last known good date / version number, language/platform specific issues (e.g. does a C# client work on Mono), etc.
On Friday, 6 April 2012 at 00:38, Roger Light wrote:
> I think there is definite merit in this idea. It may be that the place for it is on the wiki though. > I'd be keen to see some criteria for inclusion on the software page. When there were relatively few implementations every one counted. Now we can afford to be pickier and as Andy says, robustness is important. The liblwmqtt library listed had 5 source code commits over two days in 2009 and nothing since. It can only write to the network. Reading isn't supported. I don't think it benefits anybody having it listed and endorsed. On a wiki page would be another matter though. > Cheers, > Roger > On Apr 5, 2012 10:37 PM, "andyg (@geekscape)" <an...@geekscape.org (mailto:an...@geekscape.org)> wrote: > > hi All, > > > > On Thursday, 5 April 2012 at 15:38, gvmson wrote: > > > > Does anybody have positive experience using .NET-based clients with MQTT? We tried 2 libraries that are linked to mqtt.org (http://mqtt.org/) (http://mqtt.org (http://mqtt.org/)) site, got both of the to work after some debugging, but they are both failing under comprehensive testing. > > > > > > > > > Andy Piper wrote: > > > > Have you been able to contact the authors of the other .NET clients? As it says on the Software page on mqtt.org (http://mqtt.org), the completeness and testedness/stability of any implementation listed there may, unfortunately, vary :-/ > > > > > > > > > Perhaps the mqtt.org (http://mqtt.org) Software page should have the MQTT client libraries listed in a table that shows ... > > > > - Latest version number and date published > > - Some indication of quality, e.g green (known to be good), orange (not so solid), red (needs lots of work) > > - Brief comment field that might say "worked as long as we tried to send a single message or subscribe to a topic, but failed more complicated tests" > > > > Given that all the MQTT client libraries implement the specification to a greater or lesser degree, it would be good to make that situation clear. > > > > I'm happy to do extensive testing of the Lua client library (especially if we have some reference tests) and to document what parts of the specification it does and does not implement (those details are already at the top of the Lua client library source code). > > > > As more people use MQTT more seriously, then having robust clients will be fundamental to MQTT on-going success. > > > > cheers andyg (@geekscape) > > -- > > To learn more about MQTT please visit http://mqtt.org > > > > To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com) > > To unsubscribe from this group, send email to > > mqtt+uns...@googlegroups.com (mailto:mqtt%2Bun...@googlegroups.com) > > > > For more options, visit this group at > > http://groups.google.com/group/mqtt > > -- > To learn more about MQTT please visit http://mqtt.org > > To post to this group, send email to mq...@googlegroups.com (mailto:mq...@googlegroups.com) > To unsubscribe from this group, send email to > mqtt+uns...@googlegroups.com (mailto:mqtt+uns...@googlegroups.com) > > For more options, visit this group at > http://groups.google.com/group/mqtt