> I think it's important to realise that "reading spectra" covers a > wide range of possibilities and Jmol should be careful it doesn't get > sucked into a tarpit.
Thank you for your concern ... I don't think you need to worry ... read on ... Jmol is not supporting spectra in any way. Jmol will continue to stay completely focused on rendering and on clean APIs. To clarify: * This jcamp applet is planned to be a completely separate applet. * I am not doing any work on it. * It *is* being hosted in the Jmol source code repository. * I have no interest in learning anything about spectra. * The project is good for Jmol because it provides some focus for fleshing out the issues associated with applet-to-applet communication. * To date no one else has stepped forward and expressed an interest in working on that issue. [snip - many issues associated with spectra support] These are not Jmol issues. > My personal view is that Jmol, like all Blue Obelisk adopters, should > concentrate on doing its core activities excellently. IMO these are: > * molecular display > * other graphical objects (isosurfaces) (a painful subject for me :-( ) > * animation > * scripting > * event models for molecules > * a limited amount of geometry analysis I agree completely. > Many of us are working towards a component-based community, under the > BO and others. These will be integrated in modern Open frameworks > such as workflows (Taverna) and application environments > (Eclipse/Bioclipse). The Koeln group (Tobias and Miguel) have been > visiting this week and have shown some very impressive > implementations in Bioclipse. It can display spectra (Spok, Koeln), > 2D molecules, validate CML, interact with information systems, etc. > We see Jmol as a component that runs under Taverna, Bioclipse, etc. > and communicates with other components such as Spok. I agree. It is great that Jmol is a component in these java-based environments. I want to extend this 'component' model by saying Jmol needs to be easily accessible as a component in web-based environments as well. That is, within the context of html applications I think there is great value in having the ability to support one or more independent 'controller' applets that communicate with a Jmol applet, sending script commands and querying/displaying state. Fundamentally the API to Jmol is the same as for java-to-java communications, but with multiple applets on a web page there are rendezvous issues associated with establishing communication between the appropriate applets. Richard and Shravan approached me and said that they wanted to extend Henry's applet to communicate with Jmol. This was the first time that anyone raised their hand and said that they wanted to work on this applet-to-applet communication. I thought it was a good idea and I encouraged them to pursue it. You and others have raised issues about complexities of different spectra formats, duplication of effort, etc. While those are issues for someone, they are not issues for me ... because they are not issues for Jmol. As a component within the context of a web page, Jmol needs a clean rendezvous mechanism to establish applet-to-applet communication. No one else wants to work on this problem. These guys want to work on this problem. That is why this is being discussed on the Jmol mailing list. Miguel ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
