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
