KProtocolManager fit for use?

[Andreas Hartmetz]

Am Dienstag 27 November 2007 19:53:57 schrieb Thiago Macieira:
> Em Monday 26 November 2007 20:18:16 Andreas Hartmetz escreveu:
> > 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:
>
> When I prototyped the KTcpSocket class for you, I had there:
>
>     void connectToHost(const QUrl &url, OpenMode mode = ReadWrite);
>     void connectToHost(const QString &protocol, const QString &host,
> quint16 port,
>                        OpenMode mode = ReadWrite);
>
We can really lose the OpenMode, right? I can't think of any useful network 
service whose use does not involve reading *and* writing. AFAICS open modes 
are there because, for files, you can easily make sure that you don't 
unintentionally overwrite something. Sockets are temporary and have only one 
program accessing it - protection is pointless.

> Note that it differs from QAbstractSocket (QTcpSocket) by the addition of
> the extra parameter "protocol" (the triad protocol + host + port is
> perfectly represented in a URL, hence the overload -- which, come to think
> of it, should be a KUrl).
>
I overlooked that, yeah.

> Anyways, the extra parameter's only purpose is to support proxying. I
> conceived it so that multi-protocol applications like Kopete could support
> different proxies depending on the connection. At the same time, we want to
> support the vast majority of the cases: HTTP has one proxy, everything else
> uses another.
>
> My crazy ideas go as far as using JavaScript to decide what proxy to be
> used -- à la WPAD/PAC.
>
> Anyways, while the front-end is there, the backend isn't. KSocketFactory
> has a method that returns a QNetworkProxy for a given protocol+host+port,
> but is currently just a placeholder for the future. When KSocketFactory had
> a purpose, such a method could stay there, but now I don't mind if it's the
> same method as KProtocolManager.
>
> In any case, I urge you to:
> 1) not bother with this for 4.0. Let's do it calmly for 4.1. I am sure that
> KProtocolManager *right* *now* isn't suitable for your needs. It's only
> useful for web browsing (http & ftp URLs).
>
Well, that's a really difficult topic. I am not entirely sure if everything 
can be fixed after the API is frozen. There is quite some exported UI code 
that ties in to the SSL stuff. The UI code and most of the SSL API are in 
pretty bad shape generally: Awkward constructs, passing around pointers and 
names instead of const refs to the actual objects, handwritten UI code, 
methods in the wrong classes, widespread disregard for type safety (strings, 
strings, strings)...
The maintainers are all unavailable which would have been a good reason keep 
that code around. It's a minor nightmare to fix any bitrot there as it 
occurs.
The situation is comparable to KPrinter (whose complexity of the actual 
goal/complexity of implementation ratio is higher though), and I'd like to do 
something similar: Rip out the old stuff and replace it as replacements 
become ready. Basic SSL connectivity with some verification is not that 
hard - thank you QSslSocket :).
By the way, Qt's standard root certificate collection is more comprehensive 
than KDE's and KDE's needs some additions, most notably CACert.

> 2) not add the ProxyPolicy argument as part of the connectToHost function.
> Instead, add a setter/getter.
>
That would introduce a source of errors in the common case "use the KDE 
defaults" and a line of boilerplate code. Both arguments are weak and I don't 
favor any of the choices much.
Less behind the scenes magic is also good.

> Actually, for #2, there's another use-case: KGet. The idea is that it uses
> http, just like Konqueror, but the user may want to have specific proxy
> settings for large downloads.
>
> Being able to call setProxy() would be interesting (with
> QNetworkProxy::DefaultProxy meaning the configuration/script-based
> detection). KGet would just have to know its own proxies outside of the KDE
> configuration.
>
> Finally, proxy configuration is another subject of standardisation at
> freedesktop.org-level.

The docs of KPAC mention an RFC or something that has been abandoned 
meanwhile. Is there any relation?
KPAC also is already using JavaScript, I didn't investigate how well it works.
(If it's not tested it's broken :) )