<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 2:58 PM, Frank Morgner <span dir="ltr"><<a href="mailto:morgner@informatik.hu-berlin.de" target="_blank">morgner@informatik.hu-berlin.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I doubt that there is a reasonable generic and non-complex way of doing<br>
this via jni. You said it before, you would have to start the JVM from<br>
pcscd's process space. I bet you will end up hard wiring any possible<br>
configuration in the process.<br></blockquote><div><br></div><div>I can pass any information in the DEVICENAME needed, just like the pipe/socket models.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
OR you could just delegate the calls to a different Java based process<br>
(which allows this flexibility) AND use some inter process communication<br>
between pcscd and your java backend. And then you end up with a socket<br>
interface a pipe or similar ;-)<br></blockquote><div><br></div><div>Both are logically the same, your just replacing function calls to IPC pipe/socket command interface.</div><div>So the quality of the abstraction has to do with the interface design mostly, not IPC/func call.</div><div>In fact I almost have a working bridge. It's a bit more work, but reduces the amount of memory</div><div>consumption on the system (1 less process), and removes one layer of IPC. I am almost actually done.</div><div> <br></div><div>One nice thing I can do, is detect based on the methods, and attributes of the</div><div>implementing Java class, whether or not its supporting various things and handle</div><div>some of the rawness of the IFD API. Which the current loader for the .so can't</div><div>handle. The docs say to implement either </div><div>IFDHCreateChannelByName or IFDHCreateChannel. However, the loader<br></div><div>requires both symbols in the .so and fails if missing. It should check for one or</div><div>the other, not both (both should be ok too).</div><div><br></div><div>Looking at IFDHTransmitToICC() the paramater PSCARD_IO_HEADER RecvPci</div><div>is not clear to me. Looking at:</div><div>bitbucket.org:mrts/pcsclite-softemu-ifdhandler.git<br></div><div>That code doesn't even use that argument, so I guess</div><div>I can ignore it, but whats its purpose?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Greets, Frank.<br>
<div><div class="h5"><br>
On Friday, February 27 at 10:04AM, William Roberts wrote:<br>
> I might be able to contribute a Generic Java binding for the ifd layer as<br>
> well.<br>
><br>
> On Fri, Feb 27, 2015 at 8:31 AM, Frank Morgner <<br>
> <a href="mailto:morgner@informatik.hu-berlin.de">morgner@informatik.hu-berlin.de</a>> wrote:<br>
><br>
> > Yes, the documentation needs some love, but I think for a bunch of spare<br>
> > time projects its quite OK. I'll move the example cases to the sub<br>
> > components where the generic use is outlined, too.<br>
> ><br>
> > Am 25. Februar 2015 21:24:19 MEZ, schrieb Martin Paljak <<br>
> > <a href="mailto:martin@martinpaljak.net">martin@martinpaljak.net</a>>:<br>
> >><br>
> >> Hello Frank,<br>
> >><br>
> >> Maybe you should publicise your virtualsmartcard project better or<br>
> >> have the architecture or more precisely, various use cases, documented<br>
> >> even better or integrate the knowledge of these projects into<br>
> >> mainstream documentation. I did not look that much into it before<br>
> >> because I just did not understand what it was or if it related to<br>
> >> something I could use. Because most of the documentation was about<br>
> >> "virtual smart cards" and "nPA" and other German-specific terms, I<br>
> >> figured out that probably not relevant for me.<br>
> >><br>
> >> BUT it turned out that your project contains a lot of useful universal<br>
> >> APDU/PC/SC layer plumbing stuff that could really be used more (like<br>
> >> contact->nfc relay, remote ifdhandler etc)<br>
> >><br>
> >> Stuff for what support should be more integrated in open source<br>
> >> projects, really handy for debugging, testing and prototyping.<br>
> >><br>
> >> Thanks & cheers<br>
> >> --<br>
> >> Ma!<br>
> >> rtin<br>
> >><br>
> >> <a href="tel:%2B372%20515%206495" value="+3725156495">+372 515 6495</a><br>
> >><br>
> >><br>
> >> On Wed, Feb 25, 2015 at 6:34 PM, Frank Morgner<br>
> >> <<a href="mailto:morgner@informatik.hu-berlin.de">morgner@informatik.hu-berlin.de</a>> wrote:<br>
> >><br>
> >>> You can delegate the calls e.g. by using jni.<br>
> >>><br>
> >>> I am using a simple socket based interface for delegating the ifd requests,<br>
> >>> see <a href="http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html" target="_blank">http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html</a><br>
> >>> VPCD delegates the calls to everything that listens on the other side of the<br>
> >>> socket. You can find a java implementation of "the other side" in this<br>
> >>> android app<br>
> >>> <a href="http://frankmorgner.github.io/vsmartcard/remote-reader/README.html" target="_blank">http://frankmorgner.github.io/vsmartcard/remote-reader/README.html</a><br>
> >>><br>
> >>> Am 25. Februar 2015 17:01:19 MEZ, schrieb Jeffrey Hutzelman <<a href="mailto:jhutz@cmu.edu">jhutz@cmu.edu</a>>:<br>
> >>><br>
> >>> On Wed, 2015-02-25 at 07:42 -0800, William Roberts wrote:<br>
> >>><br>
> >>>><br>
> >>>> On Wed, Feb 25, 2015 at 7:28 AM, Ludovic Rousseau <<br>
> >>>> <a href="mailto:ludovic.rousseau@gmail.com">ludovic.rousseau@gmail.com</a>> wrote:<br>
> >>>><br>
> >>>><br>
> >>>>> 2015-02-25 12:16 GMT+01:00 William Roberts <<a href="mailto:bill.c.roberts@gmail.com">bill.c.roberts@gmail.com</a>>:<br>
> >>>>><br>
> >>>>>><br>
> >>>>>> That's from the client application side. I was looking for a java<br>
> >>>>>><br>
> >>>>><br>
> >>>>> binding to<br>
> >>>>><br>
> >>>>>><br>
> >>>>>> the ifd<br>
> >>>>>> interface.<br>
> >>>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> Why do you want to call the IFD handler directly from Java?<br>
> >>>>> Why not use the PC/SC<br>
> >>>>> interface?<br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> I am not explaining this properly :-P<br>
> >>>><br>
> >>><br>
> >>><br>
> >>> Perhaps not.<br>
> >>><br>
> >>> I think what you're asking for is effectively the ability to write an<br>
> >>> IFD handler in Java. For pcsc-lite, I don't think that's realistic --<br>
> >>> it would mean pulling an entire Java interpreter into pcscd. What you<br>
> >>> could do is a bridge that talks to a Java program running in another<br>
> >>> process, but I think that's going to be more troublesome than it's<br>
> >>> worth.<br>
> >>><br>
> >>> jPAM in fact does not do this; what it does is let Java applications<br>
> >>> call PAM, not the other way around. pam-python _does_ let you write PAM<br>
> >>> modules in Python; it does this by spinning up a Python interpreter in<br>
> >>> the PAM module. That works because Python is designed to be embedded in<br>
> >>> a!<br>
> >>> nother<br>
> >>> program in this way and because it will be shut down and<br>
> >>> unloaded when the module is removed, which happens no later than when<br>
> >>> the application calls<br>
> >>> pam_end().<br>
> >>><br>
> >>> -- Jeff<br>
> >>><br>
> >>><br>
</div></div>> >>> ------------------------------<br>
<span class="">> >>><br>
> >>><br>
> >>> Pcsclite-muscle mailing list<br>
> >>> <a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
> >>> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Frank Morgner<br>
> >><br>
</span>> >> ------------------------------<br>
<span class="">> >><br>
> >> Pcsclite-muscle mailing list<br>
> >> <a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
> >> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br>
> >><br>
> >><br>
</span>> > ------------------------------<br>
<span class="">> ><br>
> > Pcsclite-muscle mailing list<br>
> > <a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
> > <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br>
> ><br>
> > --<br>
> > Frank Morgner<br>
> ><br>
> > _______________________________________________<br>
> > Pcsclite-muscle mailing list<br>
> > <a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
> > <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Respectfully,<br>
><br>
> William C Roberts<br>
<br>
> _______________________________________________<br>
> Pcsclite-muscle mailing list<br>
> <a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
> <a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br>
<br>
--<br>
</span>Frank Morgner<br>
<br>
Virtual Smart Card Architecture <a href="http://vsmartcard.sourceforge.net" target="_blank">http://vsmartcard.sourceforge.net</a><br>
OpenPACE <a href="http://openpace.sourceforge.net" target="_blank">http://openpace.sourceforge.net</a><br>
IFD Handler for libnfc Devices <a href="http://sourceforge.net/projects/ifdnfc" target="_blank">http://sourceforge.net/projects/ifdnfc</a><br>
<br>_______________________________________________<br>
Pcsclite-muscle mailing list<br>
<a href="mailto:Pcsclite-muscle@lists.alioth.debian.org">Pcsclite-muscle@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Respectfully,<br><br>William C Roberts<br><br></div>
</div></div>