[Development] Qt and IoT infographic

[Jean-Michaël Celerier]

> If you're going to communicate with a tiny MCU connected over a mesh
network
like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.

What makes me a bit sad is that if Qt's not doing it, then we end up having
to put up with bloated stuff like Node.JS on beagleboard or raspberries :
https://www.postscapes.com/javascript-and-the-internet-of-things/ which are
now more and more used.
Hell, sometimes people use python of all languages on constrained CPUs.
It's a niche that Qt *could* fill, and fill better than the alternatives.




-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 10:01 PM, Thiago Macieira <thiago.macieira at intel.com
> wrote:

> On Monday, 28 August 2017 12:26:55 PDT Jason H wrote:
> > > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> > >
> > > Right now, in KF5 (kdnssd).
> >
> > And who puts/[wants to put] KDE on IoT?
>
> a) it's just one library. KF5 was designed as multiple, smaller,
> independent
> libraries that can be added to Qt programs. That's one of the reasons we
> won't
> add a .zip file API to Qt -- just use KF5Archive.
>
> b) and who puts Qt on IoT? If we're going to challenge that, then we may as
> well challenge the answer to KF5-on-IoT.
>
> > > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > > support for writing a RESTful server?
> > >
> > > Timur began working on an simple HTTP server. This is a controversial
> > > decision, since we've long said that Qt should not be the tool for
> > > server-side programs.
> >
> > It shouldn't be that controversial. We're just observing MVC and pushing
> it
> > from single-process to multi-process. We're not pushing Qt for the web
> per
> > se, just making it an equal citizen.
>
> Servers are much more complex beasts than clients. Almost every single
> vulnerability found in the Internet is related to servers.
>
> Just think of the fact that QTcpSocket has an unlimited buffer. Does this
> spell "denial of service" to you?
>
> > > But I dispute your assertion that it should be "web services". That's
> why
> > > I
> > > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> > > but
> > > not web.
> >
> > Yes, and paint yourself into a corner of the internet again. While CoAP
> and
> > REST are both mentioned on the web page, but it also says: "From a
> > developer point of view, CoAP feels very much like HTTP. Obtaining a
> value
> > from a sensor is not much different from obtaining a value from a Web
> API."
>
> If you're going to communicate with a tiny MCU connected over a mesh
> network
> like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.
>
> No, UDP, DTLS and CoAP are much more important at this stage of IoT than
> HTTP
> servers.
>
> > I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> > might be focused on IoT, but why restrict the other users to it as well?
> > Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> > hurdles for those that don't need it.
>
> I'm not saying we shouldn't, but there's a matter of priorities and
> resources.
> We can reasonably easily write a CoAP client *and* server, with multicast
> support, for 5.11. This will allow you to communicate with the MCU-class
> IoT
> devices, which should correspond to something like 80 to 90% of the 200
> billion that are expected.
>
> An HTTP server will not happen for 5.11. It's MUCH more complex and will
> require a lot more reviewing. At best, expect an early technology preview
> at
> that time, subject to API change (and not in qtbase).
>
> > Over time the number of examples/demos where Qt consumes web services has
> > grown dramatically, but Qt apps haven't really ever been able to provide
> > the internet with services. Like it or not, the internet is a bus that
> > enables modern society. And the data locked in my Qt programs can't
> easily
> > contribute to that.
>
> That's by choice. Qt applications are meant to be clients to those
> services,
> not servers.
>
> > > > b. Remove
> > > > the GL dependency for QML, so that QML can function as a way to make
> a
> > > > headless HTTP server that makes it trivial to map HTTP requests to
> > > > QObjects
> > > > or QML Elements**.
>
> > > No, QtGui, no GL, no X11, nothing.
> >
> > I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
> that's
> > just for Items? If I'm mistaken, then I am very happily mistaken!
>
> You're confusing QtQuick with QML. You asked about QML requiring GL, and it
> doesn't. You were even talking about making requests to QObjects, which
> indicated to me that you did not mean any of the existing graphical
> elements.
>
> QtQuick is the UI API on top of QML. It does require QtGui and it was
> designed
> on top of OpenGL. There was some talk a while ago about the Qt Company
> contributing a raster engine to it, but I haven't followed the discussion
> or
> checked the code. Of course, even if it happened, don't expect performance.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170829/24d56cbc/attachment.html>