Qt Network Workshop 2016

Proposed Discussion Topics

Eddy has notes that shall transform the agenda into a contents list. Just need to bring tablet to work ...

1. Redirection support
   • Should it be on by default
   • more configurable...
2. The test server
   • How can we get the image - should we replace / update it? The Vagrant solution?
   • How can we add services etc.
3. How can we better manage the various openssl builds?
   • The variations in build options, versions etc. between the platforms and distros has got to the point of insanity
4. OpenSSL 1.1 support - status update and roadmap
5. What are the main use cases for QtNetwork: HTTP(S)?
   • Are there new use cases for e.g. IoT (UDP / UPnP etc.)?
   • Implement a generic REST(?) service to make it simple to interface with a Qt application?
6. IoT
   • Identify areas of QtNetwork we should focus on (HTTP(S) / low level sockets)
   • Are there areas in QtNetwork to support the IoT story?
   • Is there input from sales or so?
7. Performance
   • try to get rid of using the bearer classes (and thread) by default, they are seldomly used (this would imply deprecating QNetworkAccessManager::networkAccessible())
8. Providing widgets for QtNetwork
   • What to do about dependencies?
   • What should we include?
   • URLBar widget (danimo)
   • SSL configuration widget (rich)
   • What about a certificate dialog?
9. Should QtNetwork's design / architecture be modified?
   • Is it outdated in any area?
   • Could it be made redundant by using a 3rd party something?
10. Providing more server support for QtNetwork
    • QSslServer
    • An HTTP server?
    • Identify use-cases

Presentations

1. High-level design and structure of QtNetwork
   • Rationale for the design.
2. New in 5.8
   • HTTP/2
   • OAuth 1+2

REST Stuff

Copied from Richard Moore's Google doc

• Provide convenience API for REST services
• Server support
• Client support
• SSL and plain text
• Separate module (or perhaps 2 one for client and one for server)

Client

• Support for ‘pre-setting’ headers to be added to requests (Eg. for auth)
• Preset base location of the API
• Have a default QNAM

• Make QML etc. use the default one normally
• Talked to tronical and even though the QML one is in the wrong thread right now, that’s just an implementation detail and can easily be changed to use the main thread
• Allows caching etc. to be setup once
• Makes use of a single QNAM much easier than it is currently
• Still allows for multiple QNAMs when the app needs different security contexts etc.
• Need to ensure the creation is thread-safe
• What do we do with the old one? Just delete it and document that you should set it early in the app lifecycle?
• Beware of people who are already holding a pointer to it

• possibly some static methods to make performing an HTTP request trivial

• QNetworkReply *QNetworkAccessManager::get(“https://example.com”);
• Not convinced these are a good idea, but they’re possible

• Easy conversions to QJsonDocument, QXmlStreamReader, others?
• Try to minimise the amount of boilerplate code needed by users

Server

• Provide a convenience QSslServer class (in qtbase)
• Provide a base-class for handling HTTP (in qtbase)
• Provide more specialised handlers such as a RESTy thing in the addon module
• Make it trivial to support both plain text and TLS with TLS being the (strongly) recommended approach

Research

• Look at some popular REST APIs
• Identify common elements that could be made easier by some convenience APIs