[Development] Qt and IoT infographic

[Thiago Macieira]

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