A few comments/ideas raised by Henry's post: > I also suspect that there must be a very wide spread of versions in that > embedding, possibly going back to Jmol 10 and even earlier. My experience is > that Jmol has excellent backward compatibility, and that there is a high > probability that the most recent Jmol is likely to work with many of these > "legacy" sites.
There was at least a couple of breaking changes between 10.00 and 11.0. Right now, I remember two: hydrogen bonds (which now require a prior "calculate" command) and "set zoomLarge". These broke my pages when I did the update, so a general, blind update of Jmol version is something I would not recommend. > However, all the journals where Jmol is embedded have no sensible mechanism > of any kind to "update" the Jmol on their servers, if they should wish to do > so. The advantages would be that even old pages (ie 5+ years old?) would > gain new features (we assume nothing breaks, perhaps a dangerous > assumption?). (See above). Another point is that some simple pages benefit from a smaller applet and a MUCH simpler popup menu, while not needing the new features. In other cases, I agree it would be good to gain new features, among them the localization (e.g. 10.00 had no Spanish interface). > I am having difficulty envisaging any sensible update mechanism which could > be implemented, but at very least, I wonder whether Jmol could have some > sort of alerting mechanism indicating what the version being used is vs what > the latest released version might be? I agree such an alert is not so much > for the benefit of the reader, but of the administrator who manages the > relevant page. A possible way for that would be the pop-up menu. Some programs put their "there is an update available" in the About menu entry. I'm not sure though about whether this is technically feasible --and it would certainly not affect the existing base of old versions-- and whether it would really be much useful in practice. > Much modern software does this, and some even highly automates the process of > updating itself (armed of course with suitable authentication). I dont think > those mechanisms could be applied to eg Web servers I don't think so either. And see the cavet above, really any version update needs human supervision so that scripts are not broken. > Has anyone actively maintained any sort of list which details what features > might have been once supported, but no longer work at all? Not really. We could try and build it communally on the Wiki. (When you remember or find one issue, you go and write it down there). I'll open a section... There it is: Wiki home page > Documentation box > Backward compatibility http://wiki.jmol.org/index.php/Backward_compatibility ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
