Re: [Development] QtNetwork changes from QtDD SF 2011

[Thiago Macieira]

On Thursday, 8 de December de 2011 12.02.42, João Abecasis wrote:
> It should be fairly simple to add an inline templated connect function that
> takes a pointer-like type, unwraps the actual pointer and calls the "real"
> connect. (e.g., using something like boost::get_pointer and hooking our
> pointer classes to it as well)

Yup. Be my guest and submit that, you're our template guru :-)

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[shane.kearns]

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

Hi,

Although the discussion seems to have moved on to an inter-process safe disk 
cache, there is a thread safe wrapper for QNetworkDiskCache attached to 
https://bugreports.qt.nokia.com/browse/QTBUG-20500 which can be used as a basis 
if QMutex locking should be used before IPC locking.

We have QSystemSemaphore for IPC locking, which may be more portable than file 
locking.
Both are vulnerable to malicious locking, although passing a randomised key to 
child processes could help the webkit case.

Unix has advisory file locks, and Windows has mandatory file locks, which could 
be used to prevent opening of a cache file that is locked by another process. 
QFile doesn't support them in Qt4.


Subject to local law, communications with Accenture and its affiliates 
including telephone calls and emails (including content), may be monitored by 
our systems for the purposes of security and the assessment of internal 
compliance with Accenture policy.
__

www.accenture.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[João Abecasis]

On 7. des. 2011, at 17.22, ext Thiago Macieira wrote:
> On Wednesday, 7 de December de 2011 09.12.39, Olivier Goffart wrote:
>>> * QObject::connect needs to be able to take a QSharedPointer
>>> * QObject::connect needs to be able to take a QWeakPointer
>> 
>> I don't understand this point: you can just pass the pointer.data() to 
>> QObject::connect, and QObject::connect automatically take care of 
>> disconnecting when the object is destroyed.
> 
> You can. This is just for convenience.

It should be fairly simple to add an *inline* templated connect function that 
takes a pointer-like type, unwraps the actual pointer and calls the "real" 
connect. (e.g., using something like boost::get_pointer and hooking our pointer 
classes to it as well)

Cheers,


João

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Thiago Macieira]

On Wednesday, 7 de December de 2011 09.12.39, Olivier Goffart wrote:
> > * QObject::connect needs to be able to take a QSharedPointer
> > * QObject::connect needs to be able to take a QWeakPointer
>
> I don't understand this point: you can just pass the pointer.data() to
> QObject::connect, and QObject::connect automatically take care of
> disconnecting when the object is destroyed.

You can. This is just for convenience.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Peter Hartmann]

On 12/06/2011 04:53 PM, ext Alexis Menard wrote:
> (...)
> - setCookieFromUrl to not be magic. It may removes/update cookies and 
> therefore If I implement a persistent storage it would be nice to know what 
> is added/removed/updated from the internal list.
> - I need some "hooks" whenever something is added/removed/updated from the 
> internal list of cookie stored by QNetworkCookieJar. Basically all the black 
> magic done by QNetworkCookieJar, I need to know about it so I can update 
> accordingly where I store my cookies (read a SQL database). I was thinking 
> that a couple of virtual method should be fine, for example :
>
> void writeCookie(const QNetworkCookie&foo) {
>
> // Store into my database
>
> // Call the base class.
> QNetworkCookieJar::write(cookie);
>
> }

yes, so as Alexis already said, we plan to introduce new virtual methods
virtual void insertCookie(...)
  deleteCookie(...)
  updateCookie(...)
  cookie(...)

which by default just do what QNetworkCookieJar currently does, i.e. 
manage everything in memory. In addition we can expose the security 
check as a new function "isCookieAccepted()" or so.

So that way one could implement a backend of choice, which could also be 
persistent; and we could have backends as Qt add-ons.

The burden of keeping everything in sync regarding several processes in 
Webkit 2 would be put on the implementor of that class; the base class 
wouldn't be able to deal with that. But since Webkit people plan to have 
a persistent cookie jar anyway I guess this would be fine.

Peter

>
> The base class just adding it into the list.
>
> - Maybe put the security filtering into a separate virtual function (to make 
> setCookieFromUrl less magical, even if the latter will call that function). 
> Make the API looks nicer to me.
>
> In the ideal world an add-on of Qt should give the possibility to have a 
> persistent storage built in (Mac OS has an API cross OS/apps for that) for 
> example a subclass of QNetworkCookieJar which already implement a SQL storage 
> for example.
>
>> * 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::connect needs to be able to take a QWeakPointer
>>
>> Ultra long term (Qt6): Fix QIODevice to do zero-copy
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Olivier Goffart]

On Monday 05 December 2011 14:50:23 Jeff Mitchell wrote:

> 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

Not possible.  (or already possible with a custom deleter)


> * QObject::connect needs to be able to take a QSharedPointer
> * QObject::connect needs to be able to take a QWeakPointer

I don't understand this point: you can just pass the pointer.data() to 
QObject::connect, and QObject::connect automatically take care of 
disconnecting when the object is destroyed.

Or do you mean that one want QObject::connect to hold a reference?
I don't think it is a good idea. Just put the receiver in a 
QList kept by the sender (or vice-versa)
Else, it is opening the pandora box of the circular references.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Jeff Mitchell]

On 12/06/2011 11:09 AM, Thiago Macieira wrote:
> On Tuesday, 6 de December de 2011 13.56.18, Jonas Gastal wrote:
>> Sorry if this is a stupid point, but there is a pretty standard mechanism
>> for
>> multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious
>> and
>> acceptable solution(to that part of the issue)? They have the same up/down
>> sides of actual mutexes.
> 
> Yes, it is, provided you do the lock file operations correctly (which isn't a 
> given).

Right -- that's why Python's lockfile uses link operations on *nix but
mkdirs on Windows. And various mechanisms may or may not work on various
other file system types (FUSE filesystems, various types of networked
filesystems, etc.) It's not an easy task.

--Jeff
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Peter Hartmann]

On 12/06/2011 04:56 PM, ext Jonas Gastal wrote:
> (...)
>>> That's a slightly different problem. With WebKit 2, we have different
>> processes,
>>> so different instances of QAbstractNetworkCache. The problem then is not
>> to
>>> make the class be thread-safe, but to make the cache methodology be
>> multi-
>>> process-safe.

Yes, it was my exact point to note that this is a different problem; and 
of course QMutex does not help here.

> Sorry if this is a stupid point, but there is a pretty standard mechanism
> for
> multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious
> and
> acceptable solution(to that part of the issue)? They have the same up/down
> sides of actual mutexes.

It might be; other options include QSharedMemory or whatever 
boost::interprocess::file_lock does.

My point was more that there might be more logic needed on top of the 
disk cache, because we had plans to keep some items in memory (as 
browsers do), which we then maybe would need to synchronize; in addition 
we would need something for a persistent cookie jar where you do not 
want to read from / write to disk for each single cookie.


So my point was: Let's keep the WebKit2 use case in mind when 
redesigning the cache / persisting the cookie jar etc.


Peter

>
> Gastal.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Thiago Macieira]

On Tuesday, 6 de December de 2011 13.56.18, Jonas Gastal wrote:
> Sorry if this is a stupid point, but there is a pretty standard mechanism
> for
> multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious
> and
> acceptable solution(to that part of the issue)? They have the same up/down
> sides of actual mutexes.

Yes, it is, provided you do the lock file operations correctly (which isn't a
given).

I was just saying that you can't use QMutex. You need to use a different kind
of mutex.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Jonas Gastal]

On Tue, Dec 6, 2011 at 1:43 PM, Alexis Menard
wrote:

>
> On Dec 6, 2011, at 12:40 PM, Thiago Macieira wrote:
>
> > On Tuesday, 6 de December de 2011 12.24.11, Peter Hartmann wrote:
> >> Another interesting thing to note is that AFAIU with WebKit 2 there can
> >> be multiple web processes per application, all using the same cache (and
> >> cookie jar), so we would need to make the cache usable by several
> >> applications at the same time.
> >>
> >> Maybe Webkit people can elaborate or know how other ports do that...
> >
> > That's a slightly different problem. With WebKit 2, we have different
> processes,
> > so different instances of QAbstractNetworkCache. The problem then is not
> to
> > make the class be thread-safe, but to make the cache methodology be
> multi-
> > process-safe.
>
> Yes, that's what we need.
>
> >
> > For example, you cannot use QMutex. You need to make it safe against
> another
> > process reading or writing to the cache at the same time without using
> the
> > normal threading primitives.
>
> Exactly.
>
>
Sorry if this is a stupid point, but there is a pretty standard mechanism
for
multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious
and
acceptable solution(to that part of the issue)? They have the same up/down
sides of actual mutexes.

Gastal.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Alexis Menard]

On Dec 5, 2011, at 4:50 PM, Jeff Mitchell wrote:

> Hello,

Hi,

> 
> I was asked to put this information on the wiki, but wasn't actually
> sure where the correct place was to do it. I'll put the info here and it
> can be moved into the wiki later.
> 
> 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

I had a chat with Peter about that.

What QtWebKit need is (though we already implemented it, work-arounding the 
current issues) :

- setCookieFromUrl to not be magic. It may removes/update cookies and therefore 
If I implement a persistent storage it would be nice to know what is 
added/removed/updated from the internal list.
- I need some "hooks" whenever something is added/removed/updated from the 
internal list of cookie stored by QNetworkCookieJar. Basically all the black 
magic done by QNetworkCookieJar, I need to know about it so I can update 
accordingly where I store my cookies (read a SQL database). I was thinking that 
a couple of virtual method should be fine, for example :

void writeCookie(const QNetworkCookie &foo) {

// Store into my database

// Call the base class.
QNetworkCookieJar::write(cookie);

}

The base class just adding it into the list.

- Maybe put the security filtering into a separate virtual function (to make 
setCookieFromUrl less magical, even if the latter will call that function). 
Make the API looks nicer to me.

In the ideal world an add-on of Qt should give the possibility to have a 
persistent storage built in (Mac OS has an API cross OS/apps for that) for 
example a subclass of QNetworkCookieJar which already implement a SQL storage 
for example.

> * 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::connect needs to be able to take a QWeakPointer
> 
> Ultra long term (Qt6): Fix QIODevice to do zero-copy
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Alexis Menard]

On Dec 6, 2011, at 12:40 PM, Thiago Macieira wrote:

> On Tuesday, 6 de December de 2011 12.24.11, Peter Hartmann wrote:
>> Another interesting thing to note is that AFAIU with WebKit 2 there can 
>> be multiple web processes per application, all using the same cache (and 
>> cookie jar), so we would need to make the cache usable by several 
>> applications at the same time.
>> 
>> Maybe Webkit people can elaborate or know how other ports do that...
> 
> That's a slightly different problem. With WebKit 2, we have different 
> processes, 
> so different instances of QAbstractNetworkCache. The problem then is not to 
> make the class be thread-safe, but to make the cache methodology be multi-
> process-safe.

Yes, that's what we need.

> 
> For example, you cannot use QMutex. You need to make it safe against another 
> process reading or writing to the cache at the same time without using the 
> normal threading primitives.

Exactly.

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> Intel Sweden AB - Registration Number: 556189-6027
> Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Thiago Macieira]

On Tuesday, 6 de December de 2011 12.24.11, Peter Hartmann wrote:
> Another interesting thing to note is that AFAIU with WebKit 2 there can
> be multiple web processes per application, all using the same cache (and
> cookie jar), so we would need to make the cache usable by several
> applications at the same time.
>
> Maybe Webkit people can elaborate or know how other ports do that...

That's a slightly different problem. With WebKit 2, we have different processes,
so different instances of QAbstractNetworkCache. The problem then is not to
make the class be thread-safe, but to make the cache methodology be multi-
process-safe.

For example, you cannot use QMutex. You need to make it safe against another
process reading or writing to the cache at the same time without using the
normal threading primitives.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Jeff Mitchell]

On 12/05/2011 06:32 PM, Thiago Macieira wrote:
> 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.

I guess what's important isn't really that it's *actually* thread-safe;
what's important is that it *appears to be* thread-safe from the
perspective of potential clients, which means that functions like get()
need to behave properly, and we need to be able to do e.g.
QNAM::setApplicationNetworkAccessManager and expect that it works across
threads.

--Jeff
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Peter Hartmann]

On 12/06/2011 12:32 AM, ext Thiago Macieira wrote:
> (...)
> 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.

Another interesting thing to note is that AFAIU with WebKit 2 there can 
be multiple web processes per application, all using the same cache (and 
cookie jar), so we would need to make the cache usable by several 
applications at the same time.

Maybe Webkit people can elaborate or know how other ports do that...

Peter

>
> This would, however, make a "clean" solution.
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Charley Bay]

On Monday, 5 de December de 2011 14.50.23, Jeff Mitchell wrote:
> > 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: ,
>

2011/12/5 Thiago Macieira 

> I've been thinking...  
>

I updated the wiki page with Thiago's comment:

https://wiki.qt-project.org/Qt_Contributors_Day/Qt_Networking_Discussion

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Thiago Macieira]

On Monday, 5 de December de 2011 14.50.23, Jeff Mitchell wrote:
> 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:

Hi Jeff, thanks for posting this.

[shame on me for not posting the one I chaired in MUC]

> 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.

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.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Jeff Mitchell]

On 12/5/2011 3:08 PM, Charley Bay wrote:
> I made a page at:
> 
> 
> 
> ...which is referenced from the front page for the Qt Contributors Day:
> 
> 
> 
> Please feel free to move-and-reorganize as needed.   I'm still learning
> the Wiki too.  ;-)) 

Great, thanks!

--Jeff
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork changes from QtDD SF 2011

[Charley Bay]

On Mon, Dec 5, 2011 at 12:50 PM, Jeff Mitchell  wrote:

> Hello,
>
> I was asked to put this information on the wiki, but wasn't actually
> sure where the correct place was to do it. I'll put the info here and it
> can be moved into the wiki later. ,
>

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. ,


I made a page at:



...which is referenced from the front page for the Qt Contributors Day:



Please feel free to move-and-reorganize as needed.   I'm still learning the
Wiki too.  ;-))

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtNetwork changes from QtDD SF 2011

[Jeff Mitchell]

Hello,

I was asked to put this information on the wiki, but wasn't actually
sure where the correct place was to do it. I'll put the info here and it
can be moved into the wiki later.

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::connect needs to be able to take a QWeakPointer

Ultra long term (Qt6): Fix QIODevice to do zero-copy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development