KProtocolManager fit for use?
Andreas Hartmetz
ahartmetz at gmail.com
Mon Nov 26 19:18:16 GMT 2007
Hi,
As I'm writing a class called KTcpSocket to resurrect and clean up SSL
support, I had the not-so-crazy idea to make it optionally (but by default)
obey proxy setting from KProtocolManager:
enum ProxyPolicy {
/// Use the proxy that KProtocolManager suggests for the connection
/// parameters given.
AutoProxy = 0,
/// Use the proxy set by setProxy(), if any; otherwise use no proxy.
ManualProxy
};
void connectToHost(const QHostAddress &hostAddress, quint16 port,
ProxyPolicy policy = AutoProxy);
/**
* Take the hostname and port from @p url and connect to them. The
* information from a full URL enables the most accurate choice of proxy
* in case of proxy rules that depend on high-level information like
* protocol or username.
* @see KProtocolManager::proxyForUrl()
*/
void connectToHost(const KUrl &url, ProxyPolicy policy = AutoProxy);
and maybe also
void connectToHost(const QHostAddress &hostAddress, quint16 port,
const QString &protocol, ProxyPolicy policy = AutoProxy);
although if in doubt I'm for shorter API docs even if that adds a line of code
here and there.
- Does *anybody* know the state of KProtocolManager, and would it be a good
idea to to use it by default?
Specifically, proxyForUrl() looks quite sophisticated but the data to feed it
(a full URL - of which the path is probably less important) often is not
available where you call connectToHost(). Especially so in TCPSlaveBase which
does not even live in the client applications' address space. It does know
the protocol which is second best after the full URL to choose a proxy.
- Would it be worth it to funnel KUrls all the way to TCPSlaveBase to satisfy
the use cases with complicated proxy rules?
Cheers,
Andreas
-----------._.-------._.-----------
,-| |-------| |
__,' | | | \
|@| | \ \
|o o '. |
\ /~~~
| __ ======='-------
\/ \/
More information about the kde-core-devel
mailing list