What about an elephant in the room, i.e. HTTP/3? Will it be implemented anytime soon?
21.11.2019, 10:55, "Maurice Kalinowski" <[email protected]>: > Hi, > > Following the notes taken on the Networking session: > > - What to do in Networking for Qt 6 > ○ https://bugreports.qt.io/browse/QTBUG-75638 is the parent > item to track > - Get rid of stale backend > ○ OpenSSL 1.1 and following supported > ○ SSL2/3 > - Additional TLS > ○ mbedTLS contribution exists, will get it in but requires > work > - QNetworkAccessmanager > ○ Default policies > - Removing bearer management > ○ There has been complaints about it > ○ Radio interfaces as bearer are not best option > ○ Legacy from S60 > ○ Let's just get rid of it and move on > ○ Webkit used bearer management to just identify whether > you're online or not > ○ However, system services exist > § We should have something similar in Qt > § WIP: Connection Monitoring > ○ Proposal: > § Remove it > § Add requested features afterwards > □ Which socket is a connection using > □ Set preferred connection > - We want to avoid temporary buffers, especially in TLS case > - QSSLsocket need to change > ○ Going through tcp socket is complicated > ○ Lots of effort, might be too big for Qt 6 > ○ Similar to QDTLS, which does not go through QUDPSocket > - (Connection loss) > ○ Problem not 100% clear > ○ We have connection caching > ○ Should not be exposed to user > - Move WebSocket to QtNetwork? > ○ Not sure why this is needed in network itself > ○ Currently not actively maintained > ○ Before moving to QtNetwork it needs to be significantly > refactored > - Removing QFTP > ○ This is about QFTP backend in QNetworkAccessManager > ○ There are still public users, but how many? > ○ Proposal: Disable it in 6.0 and check for amount of > complaints > § If limited (as expected) remove in 6.2 completely > - What about adding backends to QNetworkAccessManager? > ○ Right now you can only exchange it > ○ AP: Create research user story on JIRA > ○ Help request > - What about using libcurl as a backend? > ○ Not only ftp, but everything? > ○ It's not the best API, but provides a lot > ○ We'd have to different underlying architectures, impossible > to use libcurl with our own stuff > ○ Libcurl also has its own secure transport implementation, > etc… > ○ Windows provides native API, what about that? > § Mac probably as well > - More and more projects need to do certificate management etc > ○ KNX, OpcUA, CoAP, … > ○ Can we find an abstraction? Potentially move that into a > separate module and have Qt Network use it? > ○ QTBUG-76499, QTBUG-76876 > ○ It's a lot of work, but might be better than duplicating > less work again and again > - QUIC / HTTP3 > ○ Rather wait for it to stabilize, but on the radar > - QIODevice and zero copy > ○ Needs to move to QtCS core session as no time left > - How to test > ○ Current testserver is probably not the best option > ○ Use docker images > ○ Windows is not ready for nested virtualization > ○ However, might be worth considering run the network test > containers on one machine and then have the Windows VMs connect to this one. > > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
