Qt-Networking-Discussion

Posted by Jeff Mitchell: http://lists.qt.io/pipermail/development/2011-December/000682.html

---

At the Contributor Day in San Francisco, a number of people met to
discuss some of the issues involving QtNetwork, espcially
QNetworkAccessManager (QNAM). The overall idea is that eventually
QNetworkAccessManager, which is meant to generally be
one-per-application, must be made thread-safe in order to fulfill this
desired use.

Here are the notes from the discussion:

Long term: QNAM needs to be thread-safe (and each QNAM will be in its
own thread)
* As a result so does the cookie jar and disk cache (and these would not moveToThread())
* After that, implement QNAM::setApplicationNetworkAccessManager()
* QML can stop using multiple QNAMs and QNetworkProxyFactories (QNPFs) too.

Disk cache:

• Get implementation from somewhere which is good enough for most applications
• Set caching on by default: no

Cookie jar:

• Get Alexi to redesign the API
• Need a default persistent cookie jar: possibly?
• Talk to WebKit guys, see if we can make an addon based on their cookie jar

Application proxy:

• Use system proxy by default

System proxy config:

• Global proxy config needs to be in network manager/connection manager so there is a known place to fetch it before system proxies can be supported on non-Windows/MacOS

QNetworkProxyFactory:

• queryProxy() needs to be documented that it must be thread-safe
• proxyForQuery(): unlock mutex before calling user code

QSharedPointer:

• Use for all three (disk cache, cookie jar, qnam) so that the user can keep a ref around if they want (also for the static methods)
• Make QSharedPointer be able to delete properly with a forward declaration
• QObject::connect needs to be able to take a QSharedPointer<QObject>
• QObject::connect needs to be able to take a QWeakPointer<QObject>

Ultra long term (Qt6):

• Fix QIODevice to do zero-copy

---

Update by Thiago Macieira

…see post at: http://lists.qt.io/pipermail/development/2011-December/000693.html

<br />&gt; Long term: QNAM needs to be thread-safe (and each QNAM will be in its<br />&gt; own thread)<br />&gt; * As a result so does the cookie jar and disk cache (and these would not<br />&gt; moveToThread())<br />&gt; * After that, implement QNAM::setApplicationNetworkAccessManager()<br />&gt; * QML can stop using multiple QNAMs and QNetworkProxyFactories (QNPFs) too.<br />

I've been thinking…

QNAM is still a QObject, and so are the cache and cookie jars. They are
perfectly well attached to one thread. So we could still do cookie-jar and
cache access from that same thread, with some cross-thread mechanisms.

The cookies should not suffer any performance hit, since they are quite small
and limited in use (get them prior to sending the request, save them back
after getting the reply).

The cache, however, could be an issue. Imagine I do a get() from an auxiliary
thread, one that the QNAM and the cache are not affined to. The implementation
would need to read from the cache in one thread and make the data available to
the user, in the QNetworkReply, in another thread.

This would, however, make a "clean" solution.