Qt-Networking-Discussion: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
[[Category:Qt Contributors Day]]
Posted by Jeff Mitchell: http://lists.qt.io/pipermail/development/2011-December/000682.html
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<br /> discuss some of the issues involving QtNetwork, espcially<br /> QNetworkAccessManager (<span class="caps">QNAM</span>). The overall idea is that eventually<br /> QNetworkAccessManager, which is meant to generally be<br /> one-per-application, must be made thread-safe in order to fulfill this<br /> desired use.
-----
 
At the Contributor Day in San Francisco, a number of people met to<br />discuss some of the issues involving QtNetwork, espcially<br />QNetworkAccessManager (QNAM). The overall idea is that eventually<br />QNetworkAccessManager, which is meant to generally be<br />one-per-application, must be made thread-safe in order to fulfill this<br />desired use.


Here are the notes from the discussion:
Here are the notes from the discussion:


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


* As a result so does the cookie jar and disk cache (and these would not moveToThread())
== Disk cache: ==
* After that, implement <span class="caps">QNAM</span>::setApplicationNetworkAccessManager()
* <span class="caps">QML</span> can stop using multiple <span class="caps">QNAM</span>s and QNetworkProxyFactories (<span class="caps">QNPF</span>s) too.
 
==Disk cache:==


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


==Cookie jar:==
== Cookie jar: ==


* Get Alexi to redesign the <span class="caps">API</span>
* Get Alexi to redesign the API
* Need a default persistent cookie jar: possibly?
* Need a default persistent cookie jar: possibly?
* Talk to WebKit guys, see if we can make an addon based on their cookie jar
* Talk to WebKit guys, see if we can make an addon based on their cookie jar


==Application proxy:==
== Application proxy: ==


* Use system proxy by default
* Use system proxy by default


==System proxy config:==
== 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
* 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:==
== QNetworkProxyFactory: ==


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


==QSharedPointer:==
== 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)
* 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
* Make QSharedPointer be able to delete properly with a forward declaration
* QObject::connect needs to be able to take a QSharedPointer&lt;QObject&gt;
* QObject::connect needs to be able to take a QSharedPointer&amp;lt;QObject&amp;gt;
* QObject::connect needs to be able to take a QWeakPointer&lt;QObject&gt;
* QObject::connect needs to be able to take a QWeakPointer&amp;lt;QObject&amp;gt;


==Ultra long term (Qt6):==
== Ultra long term (Qt6): ==


* Fix <span class="caps">QIOD</span>evice to do zero-copy
* Fix QIODevice to do zero-copy


——


==Update by Thiago Macieira==
-----
 
== Update by Thiago Macieira ==


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


I’ve been thinking…
<code><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 /></code>
 
<span class="caps">QNAM</span> '''is''' still a QObject, and so are the cache and cookie jars. They are <br /> perfectly well attached to one thread. So we could still do cookie-jar and <br /> cache access from that same thread, with some cross-thread mechanisms.


The cookies should not suffer any performance hit, since they are quite small <br /> and limited in use (get them prior to sending the request, save them back <br /> after getting the reply).
I've been thinking…


The cache, however, could be an issue. Imagine I do a get() from an auxiliary <br /> thread, one that the <span class="caps">QNAM</span> and the cache are not affined to. The implementation <br /> would need to read from the cache in one thread and make the data available to <br /> the user, in the QNetworkReply, in another thread.
QNAM '''is''' still a QObject, and so are the cache and cookie jars. They are<br />perfectly well attached to one thread. So we could still do cookie-jar and<br />cache access from that same thread, with some cross-thread mechanisms.


This would, however, make a “clean” solution.
The cookies should not suffer any performance hit, since they are quite small<br />and limited in use (get them prior to sending the request, save them back<br />after getting the reply).


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


* [[:Category:Qt-Contributors-Day|Qt Contributors Day]]
This would, however, make a &quot;clean&amp;quot; solution.

Revision as of 06:25, 24 February 2015


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&lt;QObject&gt;
  • QObject::connect needs to be able to take a QWeakPointer&lt;QObject&gt;

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&quot; solution.