KProtocolManager fit for use?

[Andreas Hartmetz]

Am Dienstag 27 November 2007 21:46:50 schrieb 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
>
Ah, not really. There is some linking between the different KDE libraries and 
helper apps. Private headers then.

> > > 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.