KProtocolManager fit for use?

Thiago Macieira thiago at kde.org
Tue Nov 27 20:00:22 GMT 2007


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

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

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071127/88bc8018/attachment.sig>


More information about the kde-core-devel mailing list