KDE and smartcard support

[Aaron J. Seigo]

On Tuesday 22 May 2007, Alon Bar-Lev wrote:
> I will back off for now, since obviously, I try to add a feature that
> for some seems not important enough.

let's take a step back and try to see if there is common ground here (i think 
there is).

first, everyone would agree that having smartcard support in kde would be a 
Good Thing. so let's find a way to do that.

George, Thiago and others have an issue with a hard dependency on QCA for this 
because Qt may provide for this in the future. Qt is the preferred solution 
since we already depend on it; if Qt provides the required features in the 
future, using it will mean a smaller footprint which is nice for our users 
and fewer dependencies which is nice for people working with (building, 
developing, packaging) kde source code.

Alon points out that Qt doesn't have what is needed right now, but QCA. fair 
enough. George provides a possible solution to that in one of his emails:

		STEP 1: create an API for smartcard usage.

the API is what the rest of the world sees and is the part that musn't change 
in the future (binary and source compatibility for 4.x). the API should be 
written so that it doesn't rely on the quirks or characteristics of the real 
solution behind the scenes (e.g. QCA), much as how we mask the complexities 
of X11, gstreamer, HAL, etc... with step 1 done, then we can move to:

		STEP 2: provide a means to switch implementations

this could be as simple as a "backend" class that is optionally compiled in 
if, say, QCA is available. add a "null" backend so if there is no smartcard 
capable API available at build time, then at least the library "works" even 
if it just returns failures. the backends could even be made to be loaded at 
runtime, but that seems overkill to me. conditional compilation should 
probably be enough.

		STEP 3: write an implementation that works

you could use QCA for this if that is the Best Option right now.

this way everyone gets what everyone wants:

 - smartcard support in kde today
 - the ability to change the implementation in the future, e.g. if Qt one day 
has the needed features

reading the thread the above seems to me like it would satisfy all parties. if 
not, please correct me.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/20070522/6fa8bbe9/attachment.sig>