hi Miguel, at 4.40p EDT on 2003 December 11 Thursday Miguel Howard said: > > My goal is to extend the JmolModelAdapter API so that the CDK data > structures could optionally be released once the model is loaded into > memory. This would make it easier for a simple viewing application to take > advantage of the CDK IO facilities, then release that memory for other > uses. >
please forgive me if my understanding of this issue is somewhat naive. when Jmol opens a structure file, it is loading data from the file into its own memory space (and format). once this is done, Jmol does not go back to access the file again. correct? if that is the case, how about including a few of the most common formats in the core Jmol, then building support for different file formats as plug-ins to the app, or separate libraries for the applet? I realize this would force developers to work a little harder; however, I think user-end is more important. I think that is what you are suggesating above... for example, I use the pdb format almost exclusively. I hardly ever need to support mmol. if I create a Web page that requires mmol support, I can add the extra lib. if a third Web page requires ent support, I can add the ent lib. etc. this lets me, the developer, worry about support versus user issues. if all of my users are on a university pipe, maybe I include support for all file formats; if there are a lot of vocal modem users, maybe not ;-) does this make any sense realistically? trying to help, but somewhat out of my league, :tim -- timothy driscoll molvisions - molecular graphics & visualization <http://www.molvisions.com/> usa:north carolina:wake forest at 4.40p EDT on 2003 December 11 Thursday Miguel Howard said: > This message is about the current statue of Jmol + CDK in the area of IO > and file type support. > > So far, the beta test releases of Jmol v10 have been limited to reading > ..xyz, .mol, and .pdb files. This is because Jmol is not using the CDK > libraries to do the file IO. > > The problems are jar size, memory size, speed, JVM compatibility, and > functionality. > > > jar size > -------- > jar size is not an issue for the Jmol application. > > But size is a an important issue for the JmolApplet. We want people to > build web sites where casual users can go and look at molecules. And we > already have people asking about a 'local install' so that the applet > doesn't have to be downloaded to their machine. > > Linking with the CDK libraries almost doubles the size of the JmolApplet: > > JmolApplet.jar with SimpleModelAdapter 347,148 bytes > JmolApplet.jar with CdkJmolModelAdapter 656,664 bytes > > So, I am still trying to come up with a scheme to split the applet into > two .jar files, where the second one is downloaded only if needed. I still > do not have this working properly. > > In older versions of Jmol there were separate libraries required for CML > support. I was opposed to having the webmaster add a list of .jar files > because it confuses web developers. But I think I am now resigned to > having JmolApplet.jar and JmolApplet2.jar > > > runtime size > ------------ > The CDK data structures are rather large. > > My goal is to extend the JmolModelAdapter API so that the CDK data > structures could optionally be released once the model is loaded into > memory. This would make it easier for a simple viewing application to take > advantage of the CDK IO facilities, then release that memory for other > uses. > > > speed > ----- > Larger data structures usually mean more CPU overhead. Using the > application, reading in hemoglobin is 8-10 times slower using CDK. > > I think this could be much worse when the JmolApplet is running on an > older JVMs. > > > JVM compatibility > ----------------- > I have seen some evidence that there will be problems with the CDK > libraries on older JVMs. An easy example is the fact that some of the > method names need to change ... methods for java.util.Vector, for example. > > A harder example is the use of exceptions. As I recall, the last time I > tried to get CDK to run in the JmolApplet I was getting exceptions on the > NS JVM. Eliminating this type of problem will be slow, painful, and > frustrating. > > > Functionality > ------------- > The primary area (perhaps the only area) where this applies is with .pdb > files. CDK would need to be extended to read additional pdb record types > in order to support the kind of functionality that is needed by the > RasMol/Chime scripting language. > > I tried to make some of these changes about a month ago, but I ran into > difficulties, got frustrated, and postponed the work. > > > Summary > ------- > This is the current state of Jmol + CDK IO integration ... or lack of > integration. > > I am not really looking for any specific answers. But any > feedback/thoughts/ideas/suggestions/moral support would be appreciated. > > > Miguel > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Jmol-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jmol-developers ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
