Thanks Miguel for a truly excellent and clear summary! >Plug-in >------- >To understand a plug-in it is helpful to think back to the helper >application. A helper application is not associated with a specific web >page. Rather, it is associated with a specific file type, a specific >mime-type. The web browser will launch MS Word every time it sees a >document with the mime-type 'application/msword'.
Can I add only to this section that MIME types were never originally intended for use within browsers; they were supposed to be used only for email As a result, how browsers handle these did not develop in a very rational manner. Most browsers implemented their own MIME lookup registries, and hence they did not travel between browsers. Most browsers also created their own "plugins" directory, and this in turn was reconciled with the browser MIME registry. In the early days editing this registry was given a full GUI, but this has now largely disappeared. In the case of Safari, it seems that the MIME registry is built automatically from whatever is present in the /Library/Internet plug-ins folder, which means that since .jar application are >not< recognised as a plug-in, they cannot be defined in the MIME registry. I agree with Miguel, plugins are dying, and I think there is little future for them. The trouble is nothing very much better has replaced them. Another serious mistake early on was to propose *different* HTML code for plugins (<embed>) and applets (<applet> ); although <object> came on the scene with HTML 4.0 to reconcile these two, it has never really been adopted by most web authors (and even <object> was considered broken by HTML purists; thus its not present in the Amaya browser). After <object> never really got off the ground, along came XML, and the prospect of achieving similar effects using a combination of *namespaced* XML and stylesheets. Thus in 2000, we produced an entire journal article comprising XML, with the chemistry inlined using CML (it was not possible to truly inline legacy formats such as eg the PDB file since its is not valid xml) and the decision on how to actually display it deferred until a stylesheet was used to farm out the various displayable objects to suitable software. (if anyone is interested, this article is at http://www.rsc.org/suppdata/NJ/B0/B008780G/index.html ) Thus it was at the stylesheet stage that eg the CML was "wrapped" with HTML to be displayed with any of the mechanisms Miguel summarised so well. Well, 4 years have gone by and the world has not exactly rushed to do it this way either. That is probably due to a combination of a) The only browser that supported XML and (XSLT) stylesheets was IE; even now Mozilla does not easily manage it b) it put a far greater burden on the author to produce valid working XML and XSLT, which is far more difficult than writing simple HTML; the article above was hand crafted, and even now no simple tools to do this sort of thing have become popular c) Doing this client side could involve significant slow downs of the browser; people notice even a few seconds and get impatient! d) doing this server side requires again far more complicated technology that simply a Web server (and perhaps defining a few chemical/* MIME types). So what is the way forward? One suggestion we have been following is to abandon the Web browser for chemistry, and use Jmol to import XML directly (using the DOM model rather than the XSLT approach). This can be seen with CMLRSS. The down side of this is that we abandon non-chemistry; ie Jmol could not really be used for anything other than CML. Thus we would have to develop something different for eg Maths, Biosequences, etc etc, and we would rapidly become parochial. Its clear this issue is still causing problems (not least M$ now moving into the area of using ActiveX and hence moving rapidly into the proprietary mode of doing it); it will need some clever people to sort it out! > >As I write this it becomes more clear than ever that a Jmol Plug-in will >never exist. > > > > >That's enough for now. > Yes, perhaps we should move on from plugins! -- Henry Rzepa. Imperial College, Chemistry Dept. +44 0778 626 8220 +44 020 7594 5804 (Fax) ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
