Lists Home |
Date Index |
At 00:59 25/07/2006, Didier PH Martin wrote:
>I took a look at the Jmol CML interpreter and I can say that I was
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:
>display the applet instead of using an HTML element.
> jmolApplet(300, "script script/promotion1.en.txt");
>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.
>height=300 width=300 classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
><PARAM NAME="_cx" VALUE="7938">
><PARAM NAME="_cy" VALUE="7938">
>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
Thanks for your directed enthusiasm - it is very helpful.
>Didier PH Martin
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK