KDE and smartcard support
staikos at kde.org
Wed May 23 00:19:01 BST 2007
Look, if this whole thing is not about smartcards but instead a
backhanded way to get us to give a blind blessing to throwing away
the code that's there and using QCA, you're just wasting all our
time. This is now the 12th email I've written in the past 24 hours
on the topic, and I intend it to be my last. Follow the KDE approach
and the answer will be clear:
1) Use Qt where possible
2) Keep KDELibs to a minimum
3) Define interfaces, then implement
4) don't force code onto people
5) Follow policies implemented in kdelibs and our guidelines
On 22-May-07, at 7:09 PM, Alon Bar-Lev wrote:
> On 5/23/07, George Staikos <staikos at kde.org> wrote:
>> Make an interface, and -ignore- the implementation. What's there
>> already can do what you ask. If it switches, you won't notice. If
>> you want, as I already told you, you can reimplement KSSL, but beware
>> that it will be subject to very strict review and it's a lot more
>> work than you might expect.
> But there is no need to new implementation, we already have QCA which
> is crypto implementation that can be used by any application.
> The whole thread was started because we would like to add smartcard
> support into KDE, and by understanding that you are about to use
> QtSslSocket we know that this will be impossible mission. You can,
> however, switch into QCA and problem solved.
> We can make any API you like, including one that is very similar to
> QSslSocket. We already have something at:
> I don't wish to start maintaining a critical core KDE component, but
> supply the infrastructure of cryptography it is using. And if you
> already decided you want to switch into another implementation, all we
> ask is to use QCA one, this also solve the smartcards issue, and
> provide a common infrastructure to other cryptography in KDE.
> Best Regards,
> Alon Bar-Lev.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the kde-core-devel