[Pcsclite-muscle] IFD polling

Fri Feb 27 22:58:09 UTC 2015

I doubt that there is a reasonable generic and non-complex way of doing
this via jni. You said it before, you would have to start the JVM from
pcscd's process space. I bet you will end up hard wiring any possible
configuration in the process.

OR you could just delegate the calls to a different Java based process
(which allows this flexibility) AND use some inter process communication
between pcscd and your java backend. And then you end up with a socket
interface a pipe or similar ;-)

Greets, Frank.

On Friday, February 27 at 10:04AM, William Roberts wrote:
> I might be able to contribute a Generic Java binding for the ifd layer as
> well.
> 
> On Fri, Feb 27, 2015 at 8:31 AM, Frank Morgner <
> morgner at informatik.hu-berlin.de> wrote:
> 
> > Yes, the documentation needs some love, but I think for a bunch of spare
> > time projects its quite OK. I'll move the example cases to the sub
> > components where the generic use is outlined, too.
> >
> > Am 25. Februar 2015 21:24:19 MEZ, schrieb Martin Paljak <
> > martin at martinpaljak.net>:
> >>
> >> Hello Frank,
> >>
> >> Maybe you should publicise your virtualsmartcard project better or
> >> have the architecture or more precisely, various use cases, documented
> >> even better or integrate the knowledge of these projects into
> >> mainstream documentation. I did not look that much into it before
> >> because I just did not understand what it was or if it related to
> >> something I could use. Because most of the documentation was about
> >> "virtual smart cards" and "nPA" and other German-specific terms, I
> >> figured out that probably not relevant for me.
> >>
> >> BUT it turned out that your project contains a lot of useful universal
> >> APDU/PC/SC layer plumbing stuff that could really be used more  (like
> >> contact->nfc relay, remote ifdhandler etc)
> >>
> >> Stuff for what support should be more integrated in open source
> >> projects, really handy for debugging, testing and prototyping.
> >>
> >> Thanks & cheers
> >> --
> >> Ma!
> >>  rtin
> >>
> >> +372 515 6495
> >>
> >>
> >> On Wed, Feb 25, 2015 at 6:34 PM, Frank Morgner
> >> <morgner at informatik.hu-berlin.de> wrote:
> >>
> >>>  You can delegate the calls e.g. by using jni.
> >>>
> >>>  I am using a simple socket based interface for delegating the ifd requests,
> >>>  see http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html
> >>>  VPCD delegates the calls to everything that listens on the other side of the
> >>>  socket. You can find a java implementation of "the other side" in this
> >>>  android app
> >>>  http://frankmorgner.github.io/vsmartcard/remote-reader/README.html
> >>>
> >>>  Am 25. Februar 2015 17:01:19 MEZ, schrieb Jeffrey Hutzelman <jhutz at cmu.edu>:
> >>>
> >>>  On Wed, 2015-02-25 at 07:42 -0800, William Roberts wrote:
> >>>
> >>>>
> >>>>   On Wed, Feb 25, 2015 at 7:28 AM, Ludovic Rousseau <
> >>>>   ludovic.rousseau at gmail.com> wrote:
> >>>>
> >>>>
> >>>>>   2015-02-25 12:16 GMT+01:00 William Roberts <bill.c.roberts at gmail.com>:
> >>>>>
> >>>>>>
> >>>>>>   That's from the client application side. I was looking for a java
> >>>>>>
> >>>>>
> >>>>>   binding to
> >>>>>
> >>>>>>
> >>>>>>   the ifd
> >>>>>> interface.
> >>>>>>
> >>>>>
> >>>>>
> >>>>>   Why do you want to call the IFD handler directly from Java?
> >>>>>   Why not use the PC/SC
> >>>>>  interface?
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>   I am not explaining this properly :-P
> >>>>
> >>>
> >>>
> >>>  Perhaps not.
> >>>
> >>>  I think what you're asking for is effectively the ability to write an
> >>>  IFD handler in Java.  For pcsc-lite, I don't think that's realistic --
> >>>  it would mean pulling an entire Java interpreter into pcscd.  What you
> >>>  could do is a bridge that talks to a Java program running in another
> >>>  process, but I think that's going to be more troublesome than it's
> >>>  worth.
> >>>
> >>>  jPAM in fact does not do this; what it does is let Java applications
> >>>  call PAM, not the other way around.  pam-python _does_ let you write PAM
> >>>  modules in Python; it does this by spinning up a Python interpreter in
> >>>  the PAM module.  That works because Python is designed to be embedded in
> >>>  a!
> >>>  nother
> >>> program in this way and because it will be shut down and
> >>>  unloaded when the module is removed, which happens no later than when
> >>>  the application calls
> >>>  pam_end().
> >>>
> >>>  -- Jeff
> >>>
> >>>
> >>> ------------------------------
> >>>
> >>>
> >>>  Pcsclite-muscle mailing list
> >>>  Pcsclite-muscle at lists.alioth.debian.org
> >>>  http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> >>>
> >>
> >>
> >>  --
> >>  Frank Morgner
> >>
> >> ------------------------------
> >>
> >>  Pcsclite-muscle mailing list
> >>  Pcsclite-muscle at lists.alioth.debian.org
> >>  http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> >>
> >>
> > ------------------------------
> >
> > Pcsclite-muscle mailing list
> > Pcsclite-muscle at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> >
> > --
> > Frank Morgner
> >
> > _______________________________________________
> > Pcsclite-muscle mailing list
> > Pcsclite-muscle at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> >
> 
> 
> 
> -- 
> Respectfully,
> 
> William C Roberts

> _______________________________________________
> Pcsclite-muscle mailing list
> Pcsclite-muscle at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle

-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20150227/aadf41b8/attachment-0001.sig>