I am hoping to ask:
1. Does this basic approach seem reasonable?
I think VCardEmulType VCARD_EMUL_PASSTHRU was supposed to be used for
this case, although the current code doesn't make it straightforward
to add that, as it initializes nss in vcard_emul_init. It should be
possible to change that though.
Yeah, I didn't see a clear way to make use of that. If we're going to
proceed, and put it in libcacard, it seems to me that the nomenclature
is a bit off. That is, vcard_emul_nss.c sort of holds the 'main' entry
points (e.g. vcard_emul_init/vcard_emul_options).
Arguably, if we have a 'real' card, it seems like that stuff should
shift into vcard and/or vreader and/or a new file, and the emul stuff
should become subsidiary.
That started to become invasive in a way that messed with doing a fun
little one of POC, so I didn't :-/.
If there is a more surgical way that makes sense to you, I'd appreciate
a pointer. I tend to get myopic on these things.
It probably doesn't make much sense to push this in libcacard if you
don't reuse any of the cacard framework.
Hmm. So you're suggesting that if libcacard doesn't seem like a good
home, we should move this back to spice-gtk?
I believe that, with this change, a system that was not otherwise using a
smart card could relay that smart card on to a distant Spice server. I'm
uncertain what would happen in the case where the smart card was in use by
the local system. That's something I'll need to probe yet. I imagine that
it won't work, but have no real hard evidence for that :-/.
It could be that pcscd can actually lock concurrent requests and reply
from overlaping each others, but I don't think it can handle context
switch and apparently there is no context lock when connecting with
pc/sc api. So it will likely go wrong in some cases.
Yeah. I think my greatest fear is that it will appear to work, but go
subtly wrong in hard-to-detect ways :-/.
Cheers,
Jeremy
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel