Future of KSSL

[George Staikos]

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  
> implementation
> (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  
> QCA)
> 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!

--
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/