- 1 Discussion Topics
- 2 Feature requirements for 5.1 & beyond
- 3 Unfinished work – priority for 5.1
- 4 Areas needing attention
- 5 Using QtNetwork improvements in QtWebkit
- 6 List of Attendees
Brainstorm of items to discuss at the QtNetwork session (and hack sessions if there is too much)
Please add any topics you think should be discussed.
Priority for the main session is topics relevant to developers of other modules that use QtNetwork
We can schedule in hack sessions for the internals, but they should still be added here.
Feature requirements for 5.1 & beyond
requirements on QtNetwork by other Qt modules (including add-ons)
- any other modules – what do you need from QtNetwork?
- We deprecated QFtp due to quality issues, and removed from the QtNetwork API
- However we still need to support ftp urls in QNetworkAccessManager
- Replacement engine?
- Leave it to fade away?
- usefulness of FTP-TLS?
libproxy for linux?
- Its API can implement QNetworkProxyFactory::systemProxyForQuery
- Currently we have relatively good support for system proxy on windows and mac, but linux is basic.
- This library would give us support for PAC files, WPAD, and integration with the desktop environment settings "for free"
- Should it be autodetected in configure and enabled if available, or default to off?
- API stability – should we wait for a 1.0 release, if not then how should we deal with BIC changes
- Are there reasons not to use it (given it would be possible to configure -no-libproxy to disable it anyway)
pluggable URL scheme handlers
- This was mentioned at the LDAP session of last year's QtCS
- Implementing additional URL schemes through a plugin (e.g. "ldap://")
- public or private API? (private meaning just for other Qt modules and no BC promise)
- is it needed yet?
- how to make QNAM easily sharable
- issues with multiple QNAMs using different bearer configurations
SSL blacklist extensibility
- we added a hardcoded blacklist of certificates due to SSL CA failures in 2011
- discuss how Applications can be updated in the field when we need to blacklist certs again due to another CA failure.
- prefer not to have to rebuild Qt to do it.
Unfinished work – priority for 5.1
Asynchronous authentication / ssl error signals (QTBUG-19032 & friends)
- purpose is for GUI applications to display dialogs without requiring a nested event loop
- ssl error signals are implemented up to the socket layer
- let's work out an architecture & subtasks
Incomplete QNetworkReplyImpl / backend refactoring
- what problem was this trying to solve?
- duplicated code QNetworkReplyImpl vs QNetworkReplyHttpImpl
- if there is a plugin API, this work needs to be completed or abandoned first.
Areas needing attention
Windows native socket engine (QTBUG-24451)
- It's stable if you only use the asynchronous API, but the blocking API can fail (lose read events)
- Is there an alternative that can support the full QAbstractSocket API, and the QEventLoop API for suppressing network events.
- I/O completion ports were suggested last year, how would these work in combination with Qt event system
- Roaming API was only ever implemented by Symbian, which is gone – will other mobile platforms implement this or should it be deprecated?
QNetworkConfigurationManager implementation/design issues
- Initial implementation was not thread safe and crashed
- Current implementation has too many locks (because the locks were added remedially rather than designed in)
- There have been deadlocks due to mutex ordering problems.
- Can we improve it without changing the API?
- My "straw man" is a model used by the API that is asynchronously coupled to the backend plugins via signals
- QNetworkConfigurationManager blocks while populating the initial list – this may be slow.
- QSslSocket blocks while loading system CA certificates for the first socket used – this may be slow
- Can we make an opt-in asynchronous startup (signal emitted when ready)
- Would anyone use it?
- What about asynchronous preload?
Using QtNetwork improvements in QtWebkit
List of Attendees
- Manuel "Sput" Nickschas, mostly interested in roaming/bearer management things