Well, I have currently implemented something like you describe...
I have a server process that maintains the _single_ OCF connection to the
card, etc.
All my client code uses this server.
But, I just assumed that a reasonable extension of the threading
capabilities of OCF would be mutexing at an OS level. This could be handled
by an abstract interface implemented by platform. Otherwise, I go through
the effort of implementing extra layers in my code to handle code
synchronization and mutexing. I add a layer to my programs (in addition to
all the layers in OCF). It just seems like more of a hack than a design.
If I'm not using Unix, which is a good assumption for most people, it seems
much cleaner to go through the _same_ effort of adding layers, but have the
back end be PCSC calls to the card. I still have to write a Business
Logic -> APDU translation layer (Card Service). I still have to recognize
if the card is mine (CardServiceFactory) when it's inserted. I receive a
pretty good abstraction from hardware (PCSC). So, why would I include OCF
on top of all the other effort I'm already going through?
I really don't see as much of an advantage than I originally thought was
there. Unless you provide the infrastructure for the framework described by
Michael Bender in Solaris 8 to everyone in a cross-platform manner, then I
don't see a lot of advantage to OCF.
I don't mean this to be an OCF bashing post, I am just concerned about its
viability now. Am I missing something?
Tom McKearney
<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>
> Tom, that is a very good question and a very tough question in deed. Some
> thoughts as a first attempt to answer:
>
> It would not feel right to me if OCF would try to solve a generic problem
of how
> to synchronize programs in different virtual machines. It would also not
feel
> right if OCF would try to mess with operating system calls that are not in
the
> list of function offered by every Java implementation on every platform.
> (Although I admid that we commited the first sin in that direction already
in
> bringing "native Browser support" into OCF.)
>
> A way around this problem is the approach suggested and practiced by the
> colleagues from Sun. If I remember correctly it is called "UPI" but I
don't
> remember the meaning behind the acronym. Basically it is a setup where
OCF is
> used in a single server process that does all smart card accesses. All
programs
> needing smart card functions request the services from this one server
process.
> What bothered me with this approach is that the single process now is
> responsible for controlling who is authorized to do what type of
communication
> with the smart card. Nevertheless it seems to be a solution to the
problem you
> brought up again.
>
> Frank Seliger
> IBM Pervasive Computing Division
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
> [EMAIL PROTECTED] Tel.
+49-7031-16-3142
>
>
> [EMAIL PROTECTED] on 2000-01-22 00:54:56
>
> Please respond to "Tom McKearney" <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Frank Seliger/Germany/IBM)
> Subject: [OCF] cross-JVM support?
>
>
>
>
> Is there ever going to be a version of OCF that will support OS-level
> mutexing so that multiple JVMs can run OCF apps?
> I may have to dump OCF because of this.
> It's a big limitation.
> If you have 2 applications that need to hit the smartcard at the same
time,
> OCF can't do this. They have to be all in the same JVM.
> What if you're running a Java App on your machine and you have a Netscape
> browser window running?
> You're running 2 JVMs and OCF can't handle that.
> OCF needs to have an OS-specific extension that allows cross-JVM resource
> mutexing so that it can handle multiple apps.
>
> So, is there a plan to fix this?
>
> Tom
>
>
>
>
> ---
> > 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.
>
>
>
>
>
---
> 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.
