Q: Using a proxy or not given an url
Dawit A.
adawit at kde.org
Tue Apr 8 04:40:33 BST 2003
Hello,
Dunno why I did not see this until now :(
On Saturday 15 February 2003 09:09, Koos Vriezen wrote:
> Seems to me that proxyForURL doesn't fully cover what it name implies.
> Anyway below what I added in kmplayer (bad to copy code like that)
KProtocolManager::proxyForURL is still there because it cannot be removed for
BC reasons. Perhaps, a comment saying so would have helped...
> ....uhm this doesn't work for mms:// urls aaarch :-(
ehhh... which proxy has support for this protocol ?
> Checking 'Use same proxy server for all protocols' adds this to kioslaverc
> ftpProxy=http://localhost:3128
> httpProxy=http://localhost:3128
> httpsProxy=http://localhost:3128
> (doesn't look very extendable this way...I need another workaround :-( )
It can be changed in the future, but this is intended to make sure that we
only provide proxy support for protocols that we know are supported by actual
proxy servers...
[snipped code]
IMHO, duplicating code is a mistake. The existing API is simple enough to use
and returns a QString for a very legitimate reason stated in the
documentation. What is so hard about checking the proxy string to see if the
returned string is null or not ? If you rather not do that, how about
implementing it as shown below to avoid code duplication ?
bool proxyForURL (const KURL& url, QString& proxy)
{
(void) KProtocolManager::slaveProtocol (u, proxy);
return !proxy.isNull();
}
This way you automatically benefit from fixes that are made to
KProtocolManager. I guess I can add that to KProtocolManager and mark the
old proxyForURL deprecated as well...
Regards,
Dawit A.
More information about the kfm-devel
mailing list