> 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 <[email protected] > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
