Future of KSSL

[Jernej Kos]

On Friday 17 November 2006 15:41, George Staikos wrote:
>     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.

Well since I needed the feature fast, I thought it was simpler (and faster)to 
create a thin layer properly handling async SSL operations. Regarding all 
those features - IMO it's all about what the endusers need. And they need 
working SSL transfers much more than anything else at this moment. As I said 
in my previous e-mail, the architecture can easily be changed as soon as 
there exists an implementation that can properly handle async connections (I 
have purpusfully kept class method names the same as in KSSL so the 
implementation can be simply interexchanged without major problems).

I can also write a patch to the existing KSSL implementation, but a while back 
when I mentioned these problems to Thiago, he said that the existing 
implementation needs a rewrite in any case.

>    Sure, but SSH is completely different and not at all relevant here.

Well Brad mentioned that KFTP was using OpenSSL directly and found that wierd. 
I just specified the reason why it has to be used - some libssh methods rely 
on OpenSSL so that part can't currently be changed. But this has indeed 
nothing to do with KSSL.

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

KFTPgrabber does not use KIO slaves for network protocols. It uses a 
multithreaded approach with custom state based protocol implementations 
(therefore no blocking socket operations at all in FTP implementation) - for 
more information see engine/ftpsocket.cpp.

Regards,
Jernej Kos.