KProtocolManager fit for use?

[Andreas Hartmetz]

Am Dienstag 27 November 2007 21:00:22 schrieb Thiago Macieira:
> Em Tuesday 27 November 2007 20:27:49 Andreas Hartmetz escreveu:
> > 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.
>
> I don't think so. There are other flags in there, including the Text
> transformation (CRLF <-> LF mapping done by QIODevice).
>
> > > 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)...
>
> SSL code is not public, therefore not subject to API freeze. Problem
> solved.
>
> You can do whatever you want to in 4.1
>
class KIO_EXPORT KSSLInfoDialog : public KDialog {

and some others.

s/KIO_EXPORT// fixes that, though :P

> > 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.
>
> George can comment on that. He had pretty good reasons to keep a few
> certificates out.
>
> > > 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 :) )
>
> It works, but it's using a two-argument version of the detection (hostname
> and port). It has to be modified to be a three-argument script, which means
> WPAD scripts cannot be used for the global KDE configuration.
>
> I'd go for a simple setProxy() instead of ProxyPolicy.