The LHEATcl Plugin is an enhanced version of the TCL Plugin version 2.0 source release. The version number of the current LHEATcl release is 2.0 despite the fact that it is the first official release in order to match the version number of the TCL plugin that it "descends" from. The LHEATcl Plugin adds the following extra features to the plugin:
The "guts" of the LHEATcl plugin is a dynamically loadable library (DLL) containing the compiled object files from Tcl/Tk, FitsTcl, POW, etc. Currently, there is just one, monolithic LHEATcl DLL, unlike the LHEA standalone Tcl scripts such as fv where there one DLL for each package (Tcl, Tk, fitsTcl, POW, etc) . This library is placed in your browser's plugins directory. Currently Netscape4.x and Internet Explorer 3.x, 4.x, and 5.0 are supported. Netscape3.x is not supported because the Javascript we use to setup a window to run the tclet in doesn't work in Netscape 3.x. When your browser starts up it scans the plugins directory. If it finds the LHEATcl plugin library, it adds the LHEATcl plugin to its list of plugins and registers the plugin to process files of mime type "application/x-tcl". For details of how this information is stored in the library file, see the documentation for the Netscape plugin SDK.
Now when your browser encounters:
<embed src=http://weefle.com/myapp.tcl type=application/x-tcl>
or
<embed script='label .l -text "Hello World"; pack .l' type=application/x-tcl>
it loads the DLL (".so" file in the Unix world). We had hoped to use
a unique extension and mime type for LHEATclets rather than coopting
the original "tcl" type, but bugs in the Windows version of Netscape
prevented it. Luckily, the LHEATcl plugin should run any generic
tclets without problems.
Finally, the browser fetches the Tcl code (tclet) that started the whole process from the web server and the interpreter executes it.
To expand slightly on the above description, when your browser loads the LHEATcl DLL and finishes running startup scripts, it spawns a slave interpreter and runs the tclet in the slave interpreter. The reason for this is that the slave interpreter is restricted from doing certain insecure things. These restrictions are implemented through security policies.
For a great deal more information about security policies, see the Tcl plugin manual pages, particularily the policy and plugin architecture pages. All of the files dealing with policy and configuration are in the config subdirectory of the plugin's runtime library directory. Most of the files in the config directory are responsible for implementing various named security policy. The code in each of these files specifies what specific features of Tcl are turned on or off for that policy. So when a tclet wants to use a feature such as opening a socket to another computer save files on the browser's machine it will need to ask for a security policy that allows the use of the desired feature. For instance, a tclet wanting to send Javascript commands to the browser would need to include the line: policy javascript If the origin URL of the tclet is allowed to invoke the "javascript" policy, tclet execution will proceed, if not, the process will abort.
The file that actually sets up the behavior of your plugin config/plugin.cfg. Most of this file sets up which origin URLs can use which policies. For instance, by default, the original Tcl plugin allowed the "home" policy for any tclet, whereas the fairly dangerous features of the "javascript" policy are only allowed if the origin URL is located at SUN Microsystems. There is a "lhea" policy which allows several necessary features for our programs. Unfortunately, there is a bug in WASABI (our first major production tclet) that prevents it from running under the "lhea" policy and we haven't had time to figure out how to fix this; therefore, the LHEATcl plugin current installs configured so that any URL matching *.gsfc.nasa.gov for it's domain name is allowed to use the dangerous "trusted" policy.
The last few lines of "plugin.cfg" can be uncommented to set variables
which allow some useful plugin features, primarily for debugging tclets:
File IO in the LHEATcl plugin is somewhat complicated. By default, the plugin's security features disable writing files to the local machine entirely. However, fitsTcl's file writing does not implement any security features. The trusted policy allows unrestricted file writing on the local machine. The lhea policy allows the more limited persistent file writing. FITS file writing through fitsTcl doesn't work under Windows for the current version of the plugin. We will attempt to summarize the various possibilities here:
There are a few known quirks in the plugin or its build that need to be allowed for.
On most Unix machines, if you resize the browser window containing a tclet, the browser will crash and core dump. This is a problem with the original Tcl plugin. We prevent this for WASABI by launching the tclet in it's own, non-resizable, browser window. See the example below for details on how to do this.
It would be safer, not so much to prevent malicious intent as to guard against catastrophic bugs, if we used the 'lhea' security policy rather than the 'trusted' security policy for WASABI. We are using some forbidden feature which we have not had the time to track down. "Your mileage may vary", so try to use the 'lhea' policy if you can. This does impose some strict limits on your code, the most obvious is probably the lack of the 'menu' widget. See Tcl plugin documents for details.
As mentioned above, if you want to use cfitsio net drivers, you are limited to Unix and for Solaris you must set TCL_PLUGIN_WISH equal to 1 in the plugin.cfg file. This is done by default in our prebuilt copies of the plugin.
If you need to rebuild and/or extend the LHEATcl plugin yourself, you
are welcome to do so (read the SUN license agreement for full details
on the legal status of the plugin, the terms are pretty generous).
You may want to contact us to coordinate efforts if you're planning
extensive improvements (send email to wasabi@olegacy.gsfc.nasa.gov).
The UNIX build is fairly straightforward, we use proprietary compilers
where possible since that is how Netscape is usually built, but gcc
should work fine. The Windows build is fairly
torturous at present and requires both Borland C++ and
Microsoft Visual C++ and is not for the faint of heart, or even weak
of stomach, I suspect. The MacIntosh build uses CodeWarrior.
This example is a simple function plotter. It shows how to
create powCurve objects and graph them.
Examples
Now let's try a tclet with some fitsTcl calls. This will be a bit more complicated. Here's an annotated FITS file image display tclet:
While it's not strictly a LHEATcl question, it is handy to know how to launch a tclet in a new console window using Javascript. Here's the code to make a button that launches WASABI (a LHEATcl applet) on a the test file algol.fits:
<FORM> <INPUT TYPE="button" VALUE="Launch WASABI" onClick='goober()'> <SCRIPT LANGUAGE="JavaScript"> function goober() { var newWindow var winwidth var content if (screen.availWidth > 850 ) { winwidth = "850" } else { winwidth = "800" } newWindow = window.open("","WASABI","scrollbars,menubar,height=" + screen.availHeight + ",width=" + winwidth) content="<embed src=http://olegacy.gsfc.nasa.gov/wasabi/WASABI.tcl "+ "type=application/x-tcl height=2000 width=" + winwidth + " url=http://heasarc.gsfc.nasa.gov/wasabi/algol.fits graphname=Algol>" newWindow.document.write(content) newWindow.document.close() } </SCRIPT> </FORM>