On Friday 10 October 2003 19:28, Peter Murray-Rust wrote:
Interesting concept. Have not thought of that yet... The namespace might not be necessary btw... the hierarchy of the ChemFile might be indication enough to load certain plugins or not...
Sofar, I've just considered plugins in the way jEdit does it... the user decides which plugins should be loaded and which not...
This is always possible. The problem is when the user doesn't even know that Jmol *has* plugins!
> This may seem OTT,
OTT?
over-the-top
> but it can be seen as a considerable advantage over some > existing molecular software. This would mean that we could offer Jmol to a > user and they wouldn't need to have to know what the different plugins were > and how to install them.
True... but what about the RSSViewer plugin then? Or the DirectoryBrowser plugin I want to make... How should loading such be triggered?
I agree this is a problem. The idea I am suggesting is that the file itself triggers the plugin - as SVG does for adobe. This seems to be an area where the W3C is very weak (unless I am out of data). I used to request it regularly on XML-DEV.
for the RSSViewer there would be two strategies:
- user knows they want to read a CML-aware RSS plugin. So they boot up Jmol and tell it which feeds are available. In this case they are specified in .jmol properties. But Jmol might have the option of browsing the web and adding CML-aware RSS. These would be identified by having a CML namespace in their content.
- user receives an XML stream which (unknown to them) happens to be a CML-aware RSS feed. This is the same problem as receiving an XML file which happens to contain any namespace. The software needs to know how to manage it. In this case it would load a CML/RSS-aware tool which presumably could be offered by Jmol.
This might be a case for processing instructions. These are not part of the content but hints on how to process it. An example might be:
<?xml version="1.0"?>
<?cml 3dviewer="org.openscience.jmol.Jmol" location="http://jmol.sf.net/plugins/jmol"; help="http://jmol.sf.net/help/plugins.html";?>
<?cml 2dviewer="org.openscience.jchempaint.Jchempaint" location="http://jchempaint.sf.net/plugins/jmol"help="http://jchempaint.sf.net/help/plugins.html";?>
<cml:molecule xmlns:cml="http://www.xml-cml.org/schema/cml2/core";> </cml:molecule>
The addresses and classes are suggestions. Of course this would be specific to the CML community. But even if it isn't automatic it acts as an advertisement to the tools. There is no reason why other tools should not be included
<?cml legacyConverter="openbabel.exe" location="http://openbabel.sf.net/bin/"; help="http://openbabel.sf.net/help/executables.html";?>
Alternatively the chemical MIME mechanism could be used:
<?cml type="chemical/x-cml" href="org.openscience.jmol.Jmol" location="http://jmol.sf.net/plugins/jmol"; help="http://jmol.sf.net/help/plugins.html";?>
but without central W3C mechanisms we have to do our own thing.
I believe that it could certainly work within the community...
P.
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
