Rzepa, Henry wrote: > Egon has just posted download statistics for Jmol to the users list. > > I suspect Jmol has been embedded in 100s, if not 1000s (or even 10Ks worth) > of journal pages. 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. > > 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?). 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. 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, but perhaps someone might know of any developments in this > area? > I don't think that an automated updating mechanism would be a good thing. I am working now since more than 20 years intensively with computers. And one thing I learned from that is that most of the time there are at least some things worse than before (e.g. important features removed or unfortunately changed). And there are also almost always introduced new bugs. So the first thing I switch off after installing a new software is the automatic update function. And normally also the update notification. (An exception from this are security relevant bug-fixes.) And with Jmol these notifications would only be annoying for the users because they couldn't do anything about it anyway, only the site administrators.
Although I must admit that Jmol is one of the good examples in this respect there were a lot of changes within Jmol during the past 3 years that broke our Jmol site for some or all PDB entries. Some of these issues were fixed on the Jmol side, others on our side. And not all of them were detected before the new Jmol version was installed in the publicly available version of our Jmol interface. Essentially this means: it is a lot of work for the administrator of a Jmol site to ensure that everything is still working with a newer Jmol version (depending of course on the complexity of the site). So I rather stick to a system administrator guideline I learned: "Never change a running system!" (if it is not absolutely necessary). > Has anyone actively maintained any sort of list which details what features > might have been once supported, but no longer work at all? I don't have a list, but there are some changes I remember. The output of "show orientation" and "show boundbox" was changed severely at some point. This would break sites that parse these information. Other things that might be problematic are changes in default settings. One of the more prominent changes was "set perspectivedepth 11". As a result the effect of zoom factors drastically changed. So this might affect predefined views severely. Regards, Rolf ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
