Robert & Tim wrote: >>The user will need a way to tell Safari which file extensions should >> make it call Jmol. And yes, there needs to be some simple mechanism >> that installs the plug-in or whatever that trains Safari to call >>Jmol. (A *very* simple mechanism, please. I know almost no UNIX, and >> if I wanted to learn it, I wouldn't have bought a Mac!) >> > I think it was Miguel who mentioned using a signed applet in lieu of a > plug-in. this seems a simpler and more robust solution, but maybe I > don't understand the problem correctly. why wouldn't a signed applet > work here?
I will try to give a brief summary of the 4 different techniques that can be used to add functionality to the browser. It is important that we use the correct terminology to keep from getting confused. In order from simplest to most complex: Helper Application ------------------ A helper application is a regular application that gets automatically launched when the browser receives file that it doesn't know what to do with. The type of the file is identified by something called the 'MIME-type'. Lets look at an example using a fresh installation of Netscape/Mozilla. (We are going to say Netscape/Mozilla because Internet Explorer has some 'special' support for other MSFT products). The first time Mozilla receives a .doc file with mime-type 'application/msword' it doesn't know what to do with the file. It knows that the file is not of type 'text/html' or 'image/jpeg', so it doesn't know how to handle that file type natively. Therefore, Mozilla prompts the user to ask whether he/she wants to save the file or launch an application. If the user selects an application then he/she can choose to always launch the application when files of that mime-type are encountered. Every browser has this table of 'associations' between mime-types and applications ... although Safari's table seems to be well-hidden. A helper application can be any application ... including the Jmol app. (Note that for this scheme to work properly the web server must be configured to send the correct mime-type. This is usually not a problem for major applications. However, it is a problem for less well known file types on web servers with novice system administrators.) Untrusted (or Unsigned) Applet ------------------------------ This is a Java Applet that is embedded in a web page. Most untrusted applets are quite small and download quickly. The user never really notices them. They are little menuing system, games, etc. This type of applet is 'untrusted' in the sense that it came from some arbitrary web server some random place on the web. Therefore, we don't really trust it. Therefore, untrusted applets are placed in a tight security box. They cannot read or write to the local hard disk and they can only talk to the web server where they came from. If they try to do anything else then they are promptly decapitated. The JmolApplet is an untrusted applet ... fatter and more complex than most. Trusted (or Signed) Applet -------------------------- The security restrictions placed on an untrusted applet are rather severe. And people want to develop web-based applications that can do fancier things ... like save files to the local hard disk. Before this type of applet is executed, the browser explicitly asks the user for permission to run this applet. By saying yes the user is essentially giving permission for the software to be installed on the local hard drive. To protect all parties a Trusted Applet is *signed* with an encrypted digital signature. The encryption also ensures that the applet code has not been modified or 'played with' by a 3rd party. A 'certifying authority' is some organization that you trust to do the verification ... kind of like the Better Business Bureau. Today, there is no 'signed' JmolApplet. In the future, when there is, I will go to a 'certifying authority' and prove to them that I am a member of the Jmol project. They will then give me a digital key set. I will then use that set of keys to produce a SignedJmolApplet. When a user goes to a web page that has the SignedJmolApplet, they will be prompted and asked if they trust this applet. They will say 'yes' and the session will continue. The SignedJmolApplet that is installed on their hard drive can now read/write files on their hard drive. It can also read/write data from/to arbitrary places on the web. That will give the SignedJmolApplet a lot more leeway to do interesting things ... like read local molecular model files ... or pull files directly from databases on the web. Note that this SignedJmolApplet is still an applet that only exists in the context of a specific web page. It is not an arbitrary application that can be launched at any time. A user cannot execute it unless it is part of a web page that they have access to. However, this should include a web page that is coming from a CD-ROM or is stored in a local file system. In the future we hope to have a SignedJmolApplet. However, we will want to keep the unsigned JmolApplet for people who want to build simpler web sites that do not request/require explicit permission to write to the local hard drive. I would like to see the unsigned JmolApplet be 'lean and mean' ... with limited functionality ... but good support for just showing molecules to beginning students and casual visitors. The SignedJmolApplet will be for serious users who want more serious functionality. 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'. A plug-in functions in a similar way. But the display of the data is embedded within the browser window. At some level, it is software that extends the capabilities of the browser itself. It doesn't matter where the files come from. When the browser sees a non-native mime-type it can check its list of installed plug-ins and see if one of them can handle it. Two popular examples are Flash and Acrobat Reader. People usually install these things once and never worry about them again. Once a plug-in is installed it can do whatever it wants ... like any piece of installed software. Developing and maintaining plug-ins is very costly and expensive. Although Netscape defined a plug-in API, the fact is that the dynamic behavior of each browser on each platform is different. And many browsers 'implement/support' the Netscape Plug-in API, but they are different implementations and they have different behavior. The fundamental problem is that you are trying to take one piece of complicated software (your fancy plug-in) and embed it within another piece of complicated software (the web browser), alongside other plug-ins. And, in general, you are sharing the same memory and some of the same data structures. Therefore, when someone makes a mistake things tend to break. As I write this it becomes more clear than ever that a Jmol Plug-in will never exist. That's enough for now. Miguel ------------------------------------------------------- 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
