29.08.2017, 19:00, "Thiago Macieira" <thiago.macie...@intel.com>: > On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote: >> And yet it has a web server for serving up either a human-readable page or >> JSON on demand, and it also pushes data to a central server periodically. > > Is that a static JSON? Because if you need to compose the data on the fly, you > may also want to replace JSON with something simpler. See > https://github.com/01org/tinycbor/
This pesky people like to look up replies from their URLs in their browsers, so they want HTTP and text-based serialization. > > You'll find that the maintainer is familiar :-) > > As for the part about "pushes data to a central server", I hope it's a server > on the local network, not on the Cloud. > >> After >> reading about CoAP I think it would be a much better fit than HTTP for such >> a device, so I hope I find the time to try. But then again, browsers don’t >> have CoAP yet, so I wonder if there could be a web client that uses JS to >> talk to it. Having to build a dedicated Qt client for it would be a step >> backwards in a way, but also nice for a desktop widget or some such. > > Firefox has a CoAP addon. > https://addons.mozilla.org/en-US/firefox/addon/copper-270430/ > > As for Chrome, I'll cat with Alexis and see what he thinks about the chances > of adding it by default to the browser. > >> Qt for IoT is maybe primarily for devices that have graphically-rich >> screens. But they can be clients reading data from truly-embedded sensors, >> and they might also have data of their own to serve to other clients >> (consolidated results, or just extra sensors that happen to be attached). > > Good point on the data of their own. > > I really do think we need to reevaluate our position that Qt is for clients > only. I'm not against the HTTP server stack. I'm just saying it's a much more > complex beast. And unlike the server that serves a single page, any Qt > solution that makes to API would need to be a lot more capable. > > Otherwise, just lift the MiniHttpServer from the many unit tests. > >> There are some PLCs powerful enough to run Linux, though, like these: >> https://www.bachmann.info/en/products/controller-system/ Some industrial >> applications can afford to use them, and so can the shipping industry, as I >> learned a couple of years ago on a certain consulting gig… and so they can >> afford to use Qt too, just for network comms, even though there is no GUI. > > Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a > kernel at 1 MB, but then there's nothing left for your application. Shrinking > the kernel further is possible, but it depends on whether the upstream would > accept such changes -- for example, disabling TCP and leaving only UDP > enabled. The kernel network maintainers currently have the position that they > don't want this and you should just switch to a microcontroller RTOS at that > point. > > For Qt, we have to make sure it runs comfortably at 128 MB and we should > strive to make it possible for 32 MB of RAM. > > But the question is whether this is worth the effort. Are there devices that > have memory in this range? One anecdote I've heard is that you can't buy DRAM > at less than 512 MB -- since there's just not enough volume for them, their > prices went up, causing people to stop buying them, further causing the prices > to go up... > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
