KProtocolManager fit for use?

[Andreas Hartmetz]

Am Dienstag 27 November 2007 21:59:08 schrieb 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.
>
I should see a doctor about talking to myself so much...

# ls -R ~/kde/include/ | grep ssl
addresslineedit.h
ksysguardprocesslist.h

Only in KDE 3 was ksslall.h installed (if it isn't from some debug package or 
whatever). ksslall.h in turn contains all the SSL headers.

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