Jean-Philippe, Thank you for taking the time to write such a detailed response.
> In fact, as the Jmol code gets written, > it is normal that some features seem (to the development team at least) > to be better designed in another way than they were in Chime/Rasmol. Correct. With the benefit of hind-sight and much more powerful machines ... > There are advantages to keep the current scripting format > [snip] as well as to change it [snip]. Agreed. > There is the third option for Jmol to be able to interpret two scripting > languages that has not been discussed a lot. It's certain that there > are some disadvantages to that: need for a more complex interpreter, > need for a mechanism to distinguish the two scripting language, more > hassle for the script developer. This issue has been raised a few times, and I will take the blame/credit/responsibility for the fact that there has not been more discussion about it. My *strong* position is that Jmol needs to provide a migration path for existing Chime users. This implies that we need to have a hi-fidelity RasMol/Chime script interpreter. Once this phase of Jmol is done, and the Chime migration 'bridge' is built, then we can start to look at other extensions. The rendering engine is very much separated from the scripting engine in Jmol. And adding support for another language would not be difficult. The difficult task will be defining that language. > However, in my mind, two facts stand > clear. First, there is too much stuff out there that already uses the > Chime/Rasmol scripting language so that we can say, "no one is going to > use existing scripts anyway". Agreed. > Of course, it would be easy to modify the > current scripts - I guess there will code to change anyway when we will > definitely move to Jmol - but how time and labour-consuming this will > be! Second fact, there will be a demand for the addition of new features > to Jmol and, along with each new feature, there will be a new command > added to the scripting language (and the new command will generate a > syntax error if run in Chime/Rasmol). This is a good description of the issues which we are trying to balance. > Here I discuss some ways this option could be implemented in Jmol. > First, a script has an effect either on the molecule display or on the > "state" of the molecule in the software memory. If two languages are > supported, they can have a direct effect on the molecule; this choice > would require two interpreters. Your description is accurate. And the architecture will support this. > Alternatively, one language could be > translated into the other and the latter will affect the loaded > molecule. (Interestingly, it is stated in the Chime documentation that > CSML (a mere scripting language) is supported by Chime, in addition to > Rasmol scripts. A CSML script is just translated into a Rasmol script > and then sent to be executed). This choice would require only a script > interpreter, but also a translator. I was not aware that Chime had this kind of 'CSML' support. The direct translation option is interesting. I believe that if we were to do any translating we would be translating RasMol script into something that had a little more formal grammar and more semantic power. > It is also now a good time to think about the evolution of Jmol. I take > as an asset that the development of Jmol will be rapid and continuous: > addition of several features but nothing can be done perfectly at first, > so there will be adjustments made to the implemented features. How can > the scripting language used by Jmol cope with that? Should a script > specify the version of the language in which it is written? That is one advantage of sticking to the RasMol/Chime scripting commands until we have achieved 99% compatibility. We can avoid a lot of these issues. (As I write this I realize that perhaps I made a mistake by posting these 'axis-orientation' issues. We don't have 99% compatibility yet, so I should keep my mouth closed and keep working at high speed :-) > Nevertheless, HTML has the !DOCTYPE tag to identify the version of the > language used. However, it would be cumbersome to have an interpreter or > a translation if there are dozens of versions of different languages. That certainly would be cumbersome. > This brings us to the second problem: how to tell which language or > which version a script uses. This reminds me that Mr. Bernstein had > suggested to implement a command switch, a compromise that IMO does not > solve the problems involved: It would add a new command (for sure not > recognized by Chime, which could even less interpret the other scripting > language) and would allow the sudden switching of language into a > script, a situation that could introduce some confusion in the coding > and interpretation of scripts. For the two facts stated below, it would > not be a good idea to make a compromise language that would mix new and > old, apples and oranges :-) . I agree that mixing scripting languages sounds like a bad idea. > A solution could be to include the script > specifications as comments at the beginning of the script. Another > solution could be to handle each format differently. Each format could > have its own file extension and MIME type. I don't know yet how scripts > are handled in Jmol but there could be a way of telling the script > specifications to the applet, with a PARAM tag for instance. These will be good issues for us to think through if/when Jmol supports another scripting language. And your proposed solutions are good food for thought. > This was my two cents; I hope it will help the development of Jmol or > that it will create more debates among us, Rasmolers, Chimeleons and > Jmolers. And thank you once again for taking the time to write. !Adios! Miguel ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
