Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 00:59 25/07/2006, Didier PH Martin wrote: >Hello Peter, > >I took a look at the Jmol CML interpreter and I can say that I was >impressed. Excellent. The history of Jmol (which is relevant to this current debate) is that it came out of a simple viewer for theoretical calculations (XMol), was enhanced by Dan Gezelter, then Egon Willighagen (Dutch chemoinformatics PhD student), then Miguel (computer scientist). Over ca 5-7 years it achieved critical mass and now has many individuals contributing bits like applet wrapping, tutorials, scripts, etc. It has been adopted by Nature (one of the top scientific publishers) as their method for publishing protein structures. It is a shining example of how dedicated single individuals can generate critical mass and then becomes adopted by the community. So that is why I am so enthusiastic. >I noticed something in the main web page (ref: >http://jmol.sourceforge.net/). The demo is using a javascript call to >display the applet instead of using an HTML element. > ><script type="text/javascript"> > jmolApplet(300, "script script/promotion1.en.txt"); > </script> > >I think after having taken a look at the javascript that the jmol project >too is moving toward a layer isolating the document creator from the >browsers idiosyncrasies. For instance the previous imperative call is >translated into the following declarative code: I am sure that the Jmol developers would be interested in you thoughts here. ><OBJECT id=jmolApplet0 >codeBase=http://java.sun.com/update/1.5.0/jinstall-1_5_0_07-windows-i586.cab >height=300 width=300 classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 >name=jmolApplet0> ><PARAM NAME="_cx" VALUE="7938"> ><PARAM NAME="_cy" VALUE="7938"> ></object> > >This is the code I got in IE. The code is most probably different in Mozilla >since the latter don't understand what cabs are. In certain platforms it can >generate the <applet> element if this is what it can understand. When the >limits of declarative code are reached, imperative code comes to the rescue. >It's just a matter of thinking out of the box. > >Having this type of code is a good step toward checking PRE-CONDITIONS >before interpreting and displaying the CML document. It can make possible >that different code be generated on the basis of different browser platform. Sounds very good. >We have here the equivalent of an install program putting in place the >pre-requisites or code dependencies. Moreover, it can also check the target >platform a see that the latter support component caching and then cache the >code on the host machine so that next time, the code is loaded from the >machine instead of from the server. Sounds like JMOL people are taking the >right steps to control their run-time environment. Bravo! > >Good sign, it seems that the jmol people too got out of the trance :-) There are several fairly tightly coupled projects in this space. The main need is for someone to hack the 2D chemical editor - JChempaint - then we have a full house to populate CLAX with P. Thanks for your directed enthusiasm - it is very helpful. >Cheers >Didier PH Martin > Peter Murray-Rust Unilever Centre for Molecular Sciences Informatics University of Cambridge, Lensfield Road, Cambridge CB2 1EW, UK +44-1223-763069
|
