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