[Development] QtNetwork: using system proxy by default

[shane.kearns at accenture.com]

> -----Original Message-----
> From: development-bounces+shane.kearns=accenture.com at qt-project.org
> [mailto:development-bounces+shane.kearns=accenture.com at qt-project.org]
> On Behalf Of Peter Hartmann
> Sent: 11 October 2012 14:12
> To: development at qt-project.org
> Subject: [Development] QtNetwork: using system proxy by default
>
> Hello,
>
> I remember this has been discussed before, but yet again: How about
> using the system proxy by default, at least on some platforms or by
> configure switch? Right now every app developer has to call
> QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to
> use the system proxies.
> On desktop you might want to avoid this depending on your app, but on
> mobile (e.g. Blackberry) it might happen that you just have to use the
> system configuration and it will not work without it.

Many mobile networks have a mandatory http proxy for the access point.
System configuration is the only reasonable way to get this.

> IMO there are 4 options:
>
> 1. leave as it is, tell everybody to call above method in their app 2.
> just #ifdef for the platforms where it should be used automatically 3.
> introduce a configure switch "-use-system-proxy" or so (default no) 4.
> enable usage of system proxy globally
>
>
> 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons.
> If people think 3. is cleaner that is fine with me as well. As Shane
> told me, using the system proxy on Windows might lead to several
> seconds of delay until the synchronous method that determines the proxy
> returns, so for now 4. seems too risky.

A refinement of option 1 would be to include the setUseSystemConfiguration call in the SDK boilerplate code (along with using showFullScreen() instead of show() on mobiles).

The windows issues are documented in https://bugreports.qt-project.org/browse/QTBUG-10106
 - normally it's ok, but the worst case is terrible.
 - the worst case is reproduced with some consumer wlan routers, so affects many users.
Nobody complained yet about performance on Mac, but it's a more recent feature and hasn't been tested for perf.
Libproxy performance is unknown, I've only done functional testing.

In all cases, the API is synchronous.
For option 4, I think we need to make an asynchronous wrapper and use it internally anywhere we might block the UI thread with the synchronous version.

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