Skip to main content

[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


Back to the top