Future of KSSL
staikos at kde.org
Fri Nov 17 14:41:43 GMT 2006
On 17-Nov-06, at 4:21 AM, Jernej Kos wrote:
> the reason KFTPgrabber uses its own thin SSL class is because KSSL
> is broken
> when dealing with asynchronious sockets. So we do not use KSSL at
> all in the
> latest version.
Broken? It never really supported it... I'm curious as to why
you decided to write an incomplete SSL layer for your own app instead
of adding the support you need to KIO and submitting a patch
upstream. Apparently you have thrown away a large variety of
features and functionality in order to gain only one small one that
you wanted. This is very unfortunate because it means that user
preferences are ignored or treated differently across applications.
For that matter, if it's for FTP, we've wanted to have SSL support in
our FTP slave for quite some time now.
If all we wanted was SSL support for HTTP, it would have gone
there. The whole point of KSSL is to centralize policy decisions and
to hopefully isolate ourselves from the implementation details.
> There is also a libssh in KFTP that uses OpenSSL directly but that
> can't be
> avoided unless there exists a more high-level SSH library
> (going the "kio way" and executing an external ssh process, then
> parsing the
> results is out of the question since that is IMO a really bad thing).
Sure, but SSH is completely different and not at all relevant here.
> Otherwise KFTP can surely be ported to any new SSL interface (like
> without major problems if it is good enough. But as I see it, we
> first need
> to port KFTP to KDE4/Qt4 and that will take some time.
Why does it have to be "new SSL interface"? Why not just add
support for your one small feature to the existing one? Or better
yet, enhance kio_ftp!
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the kde-core-devel