Brion,
thanks for response.
Can you go into a little more detail on what an applet viewer might be used for?
The goal is to provide "inexperienced" users functions adaequate to "old" LizardTech, now Celartem viewer add-on like zooming, page scrolling and so on for a use in connection with our mini-DigiBib (transkription of historical/genealogical handwritings and so on).
I agree, for simply viewing a page JPG conversion is often sufficient. But bad scanned sources should be at least simple zoomable.
This - without additional manual installation of some add-on by this mentioned user. JRE is installed in many cases, a transparent applet would be good.
I understand (may be wrong) that the LizardTech add-on downloads and shows only needed page(s) at once from a given remote DJVU file too - why a applet couldn´t do so?
Concerning your security headache I think it is more comprehensible for JavaScript (sandboxes) then for Java, and MediaWiki is "swimming" in JavaScript. But ultimate decision makes the user.
Uwe (Baumbach) U.Baumbach@web.de
On Sun, Aug 7, 2011 at 10:40 PM, Uwe Baumbach U.Baumbach@web.de wrote:
Concerning your security headache I think it is more comprehensible for JavaScript (sandboxes) then for Java, and MediaWiki is "swimming" in JavaScript. But ultimate decision makes the user.
I'm not sure what you think "my" security headache is -- I'm talking about browser and OS makers disabling the Java plugin or failing to install Java in the first place. One of the reasons sometimes given is that the single-vendor Sun/Oracle JRE has a history of security vulnerabilities that are not present in browsers otherwise. (Similar concerns exist for Adobe Flash, another single-vendor plugin with a history of security vulnerabilities that are not present in browsers otherwise.) Most of the major browsers have their own JavaScript implementations, which is a healthier ecosystem to begin with, and more importantly allows each OS or browser vendor to actually ship fixes. ;)
-- brion
wikitech-l@lists.wikimedia.org