|
Nicolas Lehuen
nicolas.lehuen at gmail.com
Wed Oct 19 10:43:00 EDT 2005
A good book and a lot of reading on the web can't harm you, but your problem is not a typical web application design problem. What you must straighten out is where you card reader resides : on the client side or on the server side ? First you asked us questions about running the card reader API on the server side, and now you ask us about running it on the client side... If the card reader is on the client side, as I guess it is, then you're in deep shtrouble. How deep depends on whether the client side is closed (limited to a single enterprise) or opened (your app will be used by many customers). Neither Java or Flash applets can simply access low-level hardware nor call a C API. You could try writing a JNI wrapper around your C API and see if a signed applet loaded through the Sun JVM (which will have to be installed on the clients) can use it, but it will be difficult and non-portable. Then, you can go the plugin way but it's even more difficult than the applet way. All the more if you want to be multi-browser (as I've understood since you wrote about IE and Firefox) and multi-platform. You'll have to learn two different plugin APIs, learn COM and ATL, master the delicate art of C/C++ multi-platform programming, etc. etc. In both cases, Javascript could be used to provide the glue between the applet / plugin and the rest of the HTML app, but tthat's another level of crap to handle since supporting scripting from a plugin is not something automatically granted. Believe me, your problem is far from trivial, and given the level of the other questions you asked, it will be way out of your league. You'd better seek professional (and expensive) help. I'm sorry to be harsh but that's the sad truth. If the card reader is on the server side, then it'll be difficult (you'll have troubles with the API support for re-entrant calls or multi-threading) but far more feasable. Regards, Nicolas 2005/10/19, Philippe C. Martin <pmartin at snakecard.com>: > > PS: are these basic web dev questions, and I should just go read a book/ > join > a web design newsgroup ? > > Thanks > > Philippe > > > > On Wednesday 19 October 2005 03:03 am, Philippe C. Martin wrote: > > Hi, > > > > I have "disabled" the xml feature for now to go on with my study. > > > > I can talk to my smart card on the server side and get the information > on > > the browser. > > > > On the browser side, I will, most likely, need to write browsers > pluggins > > as it seem the only way (besides stuff like activeX which does not cover > > all the necessary platforms :-) to get access to a hardware device from > the > > browser. > > > > The current authentication mechanism my cards use requires that data go > > back and forth a couple of times between the server (master/mother card) > > and the client (child card). > > > > Also the data exchanged, if possible, must not appear on the display. So > I > > need some type of handler that'll allow that "back and forth/hidden > > exchange". > > > > My current assumption is that the two pluggins I will attack: > > firefox/mozilla and I/E will give me access to Javascript to discuss > with > > mod_python. > > > > I know a _little_ about Javascript and it always has to do with writing > and > > reading HTML tags (I'm not even sure that's the correct term) > > > > Is there some common mechanism avaialbe ? > > > > Is one of the solution to put the data on the page (maybe hidden tags > ?). > > Still there is a need for some type of synchronization between both > world. > > > > I hope my questions make sense. > > > > Thanks and regards, > > > > Philippe > > -- > ************************************* > Philippe C. Martin > SnakeCard, LLC > www.snakecard.com <http://www.snakecard.com> > +1 405 694 8098 > ************************************* > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mm_cfg_has_not_been_edited_to_set_host_domains/pipermail/mod_python/attachments/20051019/900d8d08/attachment.html
|