[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [paho-dev] Future Requirements and Releases of Paho
|
On Thu, Aug 28, 2014 at 05:27:21AM -0700, Ian Craggs wrote:
> On 08/28/2014 01:03 PM, Julien Vermillard wrote:
> > Hi,
> > some ideas:
> >
> > - maybe some MQTT test suite for testing client/broker compatibility
> > - an out of the box client for some hardware plaforms like arduino, mbed
> > with TLS security :)
> As it happens, we're doing both of those already :-).
>
> 1) I have a half completed test suite. It's next on my to do list to
> finish it
> (http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.testing.git/).
Awesome :)
>
> 2) We have an embedded client running on mbed, Linux and Arduino
> already. I'd like (and plan to create or accept contributions for)
> examples for other embedded OSes like Contiki, FreeRTOS, RIOT etc). I'll
> add the Arduino layer to Paho soon.
Running MQTT anywhere is not anymore a challenge with the new embedded
client.
>
> I have recently run the embedded C++ client with TLS security on mbed.
> So far the problem with sharing that is that the TLS library used on
> mbed (CyaSSL) is GPL licensed (not LGPL), which I think may preclude us
> from adding the interface code to Paho. Certainly we can't add binaries.
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
plateform 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.
> Ian
> >
> > I think the MQTT embedded security story could be greatly improved :)
> >
> >
> > On Thu, Aug 28, 2014 at 02:56:50AM -0700, Ian Craggs wrote:
> >> Hello all,
> >>
> >> I'm wondering what the future of Paho should look like. From two points
> >> of view: functionality and participation in the wider Eclipse community.
> >>
> >> The reason is that barring a few relatively minor enhancements
> >> (automatic reconnect, publishing when not connected, persistence), I
> >> don't see that the existing client libraries (Java, Javascript, C,
> >> Python) need a lot of new work, and could stabilize within the near future.
> >>
> >> There may be new components - client libraries in different languages,
> >> or a different style of library for a different purpose (like the
> >> embedded C/C++ APIs I'm working on at the moment).
> >>
> >> So the first question: are there Paho features, additional to the
> >> current libraries, or new components, that would be useful to the
> >> Eclipse IoT community?
> >>
> >> The second question is about participation in Mars and future
> >> simultaneous releases. If the Paho components were stable but still
> >> useful, how would Paho participate in a simultaneous release?
> >>
> >> --
> >> Ian Craggs
> >> icraggs@xxxxxxxxxx IBM United Kingdom
> >> Committer on Paho, Mosquitto
> >>
> >> _______________________________________________
> >> paho-dev mailing list
> >> paho-dev@xxxxxxxxxxx
> >> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/paho-dev
> > _______________________________________________
> > paho-dev mailing list
> > paho-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/paho-dev
>
> --
> Ian Craggs
> icraggs@xxxxxxxxxx IBM United Kingdom
> Committer on Paho, Mosquitto
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/paho-dev