Right, so that would be even better, and we can definitely try that.
I've run some tests that put different readers in different jar files to see what happens. Here's the problem I see right now: 1) When you load the applet, even if you never ever use any of the classes in a particular jar file, that jar file is still downloaded if it is listed on the class preloader INDEX.LIST. I've tried this several times now with my own webserver, and it's clear that all the jar files are delivered BEFORE the model file is requested. I guess that's what "preloading" is all about, right? So if it's going to be in a jar file, unused classes can't be in Jar files on the INDEX.LIST, I think. 2) If the jar file is NOT on the list, then that file doesn't load until it is needed. But there's a catch. What happens is that as soon as one item that has not been loaded is requested, then all the remaining Jar files are transferred, because JVM has no idea which jar file to load. It just loads them all, or at least until it finds the class it needs. And since a browser may go after its files using multiple simultaneous threads (I see up to FIVE active "users" on my server when just one browser is getting files), I've even seen it look for the class file even though the right jar file is currently being downloaded. These browsers really go all out! HOWEVER, If you instead just supply the class file and no more jar files, then that class file is read immediately. So I think the solution is to simply provide a very light version, with only a miminum set of readers -- perhaps even just XYZ -- and let the developer put whatever class file he/she wants on the server along with those. I'll do more tests.... Please try http://www.stolaf.edu/academics/chemapps/jmol/temp/class/simplejar.htm and tell me if this seems fastr than , say, http://www.stolaf.edu/academics/chemapps/jmol/docs/examples-11/new.htm I think the only readers included there are XYZ, MOL, MOL2, and CIF. But then if you call up a console and do load water.out you will see that a GAMESS file will load -- because if you look in http://www.stolaf.edu/academics/chemapps/jmol/temp/class/org/jmol/adapter/readers you will see that I put that one class file in as well. So it loads when you need it. I tried putting the class file in the directory of the file and directing the Resolver to load "GamessReader.class" instead of "org.jmol.adapter.readers.GamessReader.class", but that was not successful. It appears that the class file knows that it must be "org.jmol.adapter.readers.GamessReader.class" and instead fires an exception. If there is a way to do it with a jar file, that would be fine. Bob Nicolas Vervelle wrote: >Bob Hanson wrote: > > >>3) By pre-specifying what file types will be used, Jmol.js can build an >> applet tag that only loads code for those specific file types, >> or at least a small subset containing them and a few others. >> I suggest something like: >> >> jmolSetFileTypes("xyz,mol,cif,pdb") >> >> or even, >> >> jmolSetFileTypes("file=xxxx.class,file=yyyy.class") >> >> which means simply that you will provide your own .class files for >> the specific readers you need. >> >>4) By pre-specifying what options will be used, Jmol.js can build an >> applet tag that only loads a limited amount of the functionality >> capable in Jmol. I suggest: >> >> jmolSetOptions("nobio,noxtal,nothis,nothat") >> >> >> >Why don't we simply split Jmol into several jars ? >Like it's currently done, but with a better partition ? > >The current problem, as I said in a previous mail, is that at least one >class is required in each JmolAppletX.jar for even the most basic stuff. >That's why everything needs to be loaded before Jmol can run. > >If we split Jmol into well thought jars, we should achieve the same >speed increase in loading without needing special calls from the web >page designer, and without restrictions on functionality. > > > > >>Here's how we get there: >> >>1) We modify Jmol to be more flexible in its file loading. That I >> can do today with no problem. Kind of a pain, but it will be worth it. >> >>2) We modify Jmol to be more flexible in regard to loaded options. This >> is trickier, because we will have to automatically produce appropriate >> menus. That's easier than it might sound, because we actually do that >> anyway, but it will take more considered thought. >> >>3) We modify Jmol.js to deliver different sets of jar files depending >> upon user specifications. >> >>4) We do some road tests to see how much of a difference all this makes. >> >> >>I'm starting on (1) now. >> >>If someone else could work on the Jmol.js part, that would be great. >> >>If someone has better ideas, tell us now! >> >> >> > >Several jars ;) > >Nico > > >------------------------------------------------------------------------- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >_______________________________________________ >Jmol-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/jmol-developers > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
