KDE and smartcard support

[Andreas Aardal Hanssen]

On Wednesday 23 May 2007 11:25, Alon Bar-Lev wrote:
> ... provided by Trolltech ... If Trolltech will provide cryptography...
> ...provider that use Trolltech when available... Once Trolltech will ...

[OT] I thought this was about KDE, and Qt, the framework KDE is written in and 
that also serves as QCA's foundation. Why do you keep writing "Trolltech"? 
Can we clear away some steam here, please? This discussion is pointless if 
your intention is to make some strange personal point.

> The first advantage of using QCA throughout KDE applications is to
> The second advantage of using QCA is its modular approach. It was
> The third advantage of using QCA or any common API is that the user
> The forth advantage of using QCA is enabling applications to handle
> But in order to achieve this, we should improve the whole
> cryptographic framework KDE is using.
> I agree with this, and I am sure QCA implementation follows the same
> approach.
> I am looking at QCA as a candidate for this API.
> Please remember that QCA, unlike OpenSSL, is Qt friendly implementation.
> So instead of inventing one more API, just look at the QCA abstraction
> as STEP 1.

Come on, we all agree cryptographic support is important. KDE needs it. Qt 
provides some, QCA provides some. We can make the two work together, as 
Justin wrote, it's not a big deal. You are giving the impression that you 
want everyone to scrap what they have and start using QCA for everything. You 
even said you want to write a replacement class for QSslSocket. But a few 
mails earlier you wrote:

"I don't wish to start maintaining a critical core KDE component."

Note also that nobody else in this thread seems to be saying "scrap what you 
have, and use XXXX instead". We're saing "here's what we've got, now how do 
we use it". Now please go back and look at Aaron's summary.

-- 
Andreas Aardal Hanssen / bibr - andreas . hanssen @ trolltech.com