Hi guys, I'd really like proxy support for OSCAR - preferably standard HTTPS CONNECT. My net connection now consists of dialing up to work (after dragging my computer downstairs) and getting a 192.168.x.x IP; thus, proxy support is a must for me, and just standard HTTP proxy stuff. Cheers, Daniel (Complementary to Bug#63458)
oscar uses KExtendedSocket now, and so I thought that was built-in, or am I missing something?
Subject: Re: Proxy support for OSCAR On Tue, Nov 18, 2003 at 11:46:13PM -0000, Matt Rogers wrote: > oscar uses KExtendedSocket now, and so I thought that was built-in, or am I missing something? Sort of. You do need to tell it to actually use a proxy, but it does take care of everything past there. Basically, you need the UI, and a small fragment of code. I tried to find an example, but no dice - maybe Martijn knows?
KExtSock can do SOCKS proxying, but not HTTP(S) proxying. It's in my TO-DO list, though. I want to provide a kcm-like module that would allow applications to change their proxy settings. Something like: ( ) Don't use proxy ( ) Use global configuration ( ) Use these configurations: ( ) SOCKS server: port: or ( ) HTTP server: port: It might also be interesting to do this per protocol (or per account) in Kopete. Imagine, for instance, a local Jabber server and the global ICQ network, the latter being accessible through a proxy server, but the former must be accessed directly.
Subject: Re: Proxy support for OSCAR On Wed, Nov 19, 2003 at 01:01:15AM -0000, Thiago Macieira wrote: > KExtSock can do SOCKS proxying, but not HTTP(S) proxying. It's in my TO-DO list, though. Cool stuff. > I want to provide a kcm-like module that would allow applications to change their proxy settings. Something like: > > ( ) Don't use proxy > ( ) Use global configuration > ( ) Use these configurations: > ( ) SOCKS server: port: > or > ( ) HTTP server: port: > > It might also be interesting to do this per protocol (or per account) in Kopete. Imagine, for instance, a local Jabber server and the global ICQ network, the latter being accessible through a proxy server, but the former must be accessed directly. Yeah, that's what I was about to say - you really can't have a global setting for something like this. Thanks for all your work, looks way cool. Are you able to provide this bug with an example of a code snippet you'd add to KES initialisation to enable proxying? :) d
Unfortunately, KExtendedSocket will be deprecated by then. The much simpler (and yet more powerful, if I get what I want) interface in the qt-addons library will be in use. The code will be something like this: QStreamSocket sock; sock.setSocketDevice(new QHttpProxySocketDevice(proxyhost, proxyport)); sock.connect(); It might be possible to do the same with KExtendedSocket, since it will be updated to use those classes as well. Therefore, there might be a way of exposing the a similar setSocketDevice() call.
Subject: Re: Proxy support for OSCAR On Wed, Nov 19, 2003 at 01:25:04AM -0000, Thiago Macieira wrote: > Unfortunately, KExtendedSocket will be deprecated by then. The much simpler (and yet more powerful, if I get what I want) interface in the qt-addons library will be in use. > > The code will be something like this: > QStreamSocket sock; > sock.setSocketDevice(new QHttpProxySocketDevice(proxyhost, proxyport)); > sock.connect(); > > It might be possible to do the same with KExtendedSocket, since it will be updated to use those classes as well. Therefore, there might be a way of exposing the a similar setSocketDevice() call. If I'm ever near you, you're getting a free beer.
Having the ability to use HTTP based proxies in Kopete is vital for it's acceptance in the corporate world. My company uses aim extensivly but we are all dependent on HTTP proxy, probably around 30,000 - 40,000 users worldwide in my company alone. Until Kopete can handle proxies, gaim will still be my number 1 choice.
Can we remove useless comments on bugs.kde.org? The last one really doesn't belong into a bug database.
Subject: Re: Proxy support for OSCAR On Thu, Nov 20, 2003 at 07:22:00PM -0000, Svein Brostigen wrote: > Having the ability to use HTTP based proxies in Kopete is vital for it's acceptance in the corporate world. > > My company uses aim extensivly but we are all dependent on HTTP proxy, probably around 30,000 - 40,000 users worldwide in my company alone. > > Until Kopete can handle proxies, gaim will still be my number 1 choice. May I suggest Jabber, which ... it's not designed for corporate environments per se, but its design certainly lends itself to corporate situations very well, and it was certainly in the minds of the designers when it was designed. It's a fantastic protocol, brilliantly flexible, very featureful, you can run your own servers, and, best of all, the Kopete Jabber plugin has HTTP proxy support. What's not to love? :) http://www.jabber.org/about/overview.html, Daniel
Subject: Re: Proxy support for OSCAR On Thu, Nov 20, 2003 at 07:36:15PM -0000, Stefan Gehn wrote: > Can we remove useless comments on bugs.kde.org? The last one really doesn't belong into a bug database. I think it does; it's a useful insight. Please don't discourage users from reporting their experiences.
> Can we remove useless comments on bugs.kde.org? The last one really doesn't belong into a bug database. There is nothing wrong with stating that somebody considers a bug important. ___however__, ideally, people should be voting for it, or encouraging others who consider it important to vote also. It's interesting that people who consider this a "must" don't even vote for it, when it's rather been well proven that developers _do_ pay attention to bugs with larger amounts of votes, at least in the scope of KDE. I just voted for it, because I consider this bug important. If you also consider it important, vote for it. It's probably more beneficial than just saying that it's important.
In this specific case, it depends on me and I won't get any more free time to code when people vote for the bug. I will implement this when time permits. Yes, we all know that HTTP-proxy support is very important. I've even been offered help to do this, but it won't come out before I get the new classes right. So, read: KDE 3.3 minimum, likely KDE 4. But rest assured that this will be implemented. It's in my TO-DO list and has been for a year at least.
This is probably a duplicate of bug #62520 (also in kopete).
*** This bug has been marked as a duplicate of 62520 ***