Qt-contributors-summit-2014-QtCS14QtNetwork: Difference between revisions
Jump to navigation
Jump to search
(Restore 2014 qtnetwork session notes) |
m (Refined a category.) |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Category:QtCS2014]] | |||
[[Category:Developing Qt::Network]] | |||
=CI problems= | =CI problems= | ||
Line 28: | Line 30: | ||
=<span class="caps">SSL</span>= | =<span class="caps">SSL</span>= | ||
* Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of | * Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new <span class="caps">API</span>. | ||
* The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to | * The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to "overacceptance", essentially to <span class="caps">SSL</span> errors. | ||
* Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear <span class="caps">API</span> that just needs to be hooked into Widgets/QML. | * Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear <span class="caps">API</span> that just needs to be hooked into Widgets/QML. | ||
Latest revision as of 17:02, 6 January 2017
CI problems
- Network tests fail a lot. Proposed solutions to avoid running network tests:
- Move QtNetwork into its own git module
- Thiago: Network cannot swapped out into its own module, due to dbus reqiring it in the future
- Only run network tests when code affecting QtNetwork has changed -> more likely
- Gurantees for VMs
- CPU time
- Swapping a problem?
- Proposed Solution: Give more resources to VM tests. Frederik to take care.
- Debugging of Network error causes:
- Rich and Peter to sign NDA with Digia to get VPN access. Tuuka is involved, will start after holidays
- CI resources are not well used, getting fixed in the future (Frederik)
SOCKS Proxy code
- The code is horrible (Thiago)
- We are not currently testing against SSH (the most common usecase probably), only Dante
- The tests have been unstable, will be disabled for now
- Rich volunteered to look into it at some point
NTLM
- Tests are disabled
- Before, we used Linux machines. Would be nice to also run against Windows Servers to get coverage for Domain credential use.
- Digia would get a Windows Server VM up and running, danimo to provide instructions to Frederik
SSL
- Rich hates the SSL errors API, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new API.
- The new API would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current API leads to "overacceptance", essentially to SSL errors.
- Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear API that just needs to be hooked into Widgets/QML.
Qt 5.4 goals
- Rich: QSslServer Class, in lieu of QTcpServer
- Peter: Persistent Store: TLS session tickets, HSTS, Intermediate Certs,Cookies
- iOS backend progressing well, would be nice to get in