(Note, philosophical discussion to follow)
> To explain: My viewpoint is that of creating applications that use
> smartcards as one feature of their operation, in a user-centric way. i.e.
> IF the user has a smartcard, they may be able to use it with my
> application. As a result, ease of reader installation and trouble-free
> running is the order of the day! Buggy drivers and installation of
> multiple obscure .EXE files in the right order and not hot-plugging
> devices as you can other devices, is not what end-users will endure if
> given a choice.
We (the industry) should turn this problem around. If I develop an
application that needs to read and write a file, I don't also have to
bring along the filesystem code and the disk drivers as well, yet
that's where we are in today's world with respect to smartcards! Why
do you, as an application developer of an application that uses
smartcards need to worry about reader drivers, EXE files, ocf.jar,
pcsc.dll, etc...? Why don't operating systems have native (in the
"included by default" meaning of that word) smartcard support?
My opinion is that the market for smartcards on computers is just
not big enough (and will it ever be) compared to devices like
telephones, cell phones and mass transit applications. There is not
yet enough customer pull for smartcards on the desktop. Witness
for example Microsoft's recent exodus from the smartcard arena.
One has to scratch their head when one sees Microsoft leave any
area of technology!
So, what do we see customers deploying in the real world? We see
them deploying proprietary solutions from ActivCard, Gemplus,
Schlumberger, Bull, etc..., solutions for which a high level
framework like OCF or even PC/SC is not really necessary.
Customers are surely interested in "open standards" until they
see that the "open standards" on one platform do not play with
the "open standards" on another. So, what is their response? They
go to a vendor that provides them with a proprietary smartcard stack,
APIs and complete application integration. Sure it's proprietary,
but it works the same way on their UNIX platforms as it does on
their WinTel platforms as it does on their PDAs as it does on
their cell phones, and usually the top level of that stack provides
the real APIs that the customer needs such as PKCS#11, free-form
data store, e-purse, etc...
What does this say for frameworks like OCF and PC/SC? In my
experience it says that currently what's needed is a solid
reader abstraction layer, but that we're not yet ready for
putting a card abstraction into a generic framework like
OCF or PC/SC.
I hope this isn't hearasey :-).
mike
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
