Qt Crypto Architecture for KDE4?

[Thiago Macieira]

George Staikos wrote:
>  Basically no, except observe memory footprint issues.  KOpenSSL was
> designed purely to demand-load OpenSSL.  The overhead of linking
> directly to OpenSSL is quite large, and was a show-stopper for KDE 2.0.

Another issue here is that OpenSSL developers haven't yet found out about 
the wonders of Binary Compatibility, which we so praise. Linking to 
OpenSSL is prohibitive as they keep changing the API without changing the 
library sonames. Therefore, dynamically loading it and using only the 
strictest set of calls is a good compromise.

(A good example of the opposite is libidn: version 0.5.8 is libidn.so.11)

Take a look at KOpenSSL's initialisation code: it tries several versions 
of the SSL initialisation routines. That allows KDE to be mostly freed 
from upgrading everytime OpenSSL is released. The same can be 
accomplished by QCA with its plugin, but it will require (binary) 
distributions to release a new package containing the recompiled plugin.

There's also the fact that OpenSSL is licensed under an old-BSD-like 
license, which is, AFAIU, GPL-incompatible (it contains the advertising 
clause).

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050912/9a616c2b/attachment.sig>