Theoretically I agree, however, this restriction is quite unfriendly and reduces the usefullnes. For example one cannot create (easily) tutorials which could be distributed on CD or downloadable as a zip file. If the applet arrives from the web server, only predefined files from the server can be loaded. If started locally only the files from the same folder can be used, as the load command intentionally does not understand paths in names. Therefore arbitrary local files cannot be loaded, or must be copied to the applet's folder... Is it necessary to start from the assumption that the jmol applet is a potential malicious piece of code? From this respect the plugin solution is better, even if it must be installed by the user. (A plugin cannot be malicious?). Maybe it would be good that when locally initianting, the applet could read relatively downwards the directory tree, but not upwards (so absolute paths and ../ are not allowed, but ./fee/foo/this.mol yes)
By the way, this behaviour should have been documented. regards Tamas >Yes, this is normal "local" operation. The idea is that the applet, for >security reasons, should not be able to read just any file on your local >system. (Sounds like a good idea to me!) >For local operation, you need to have all model files in the directory >containing the .jar file or a subdirectory of that. (Jmol.js can be >anywhere.) Right now you have caffein.xyz in the directory of the html, >ABOVE the directory containing the .jar file. So it works via http:// >but not file:/// >Bob Hanson ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
