R-alpha: ramblings on plug-ins

Luke Tierney (luke@stat.umn.edu)
Sat, 1 Feb 1997 14:37:33 -0600 (CST)


From: Luke Tierney <luke@stat.umn.edu>
Message-Id: <9702012037.AA25387@nokomis.stat.umn.edu>
Subject: R-alpha: ramblings on plug-ins
To: r-testers@stat.math.ethz.ch
Date: Sat, 1 Feb 1997 14:37:33 -0600 (CST)

This is a note I posted to the stat-lisp-news mailing list in response
to a note on that list. Since it also addresses R I tought I'd post it
here too.

-------------------------------------------------------------------------------

Anthony Rossini raised the possibility of making a Netscape plug-in
for XLISP-STAT or R. I've been thinking about the issues for a while,
so I thought I'd write down some notes and send them out for
reactions.  This is kind of long and rambling - you know what key to
hit if you're not interested :-).

A couple of preliminaries. There is a book on plug-ins available,

	Netscape Developer's Guide to Plug-Ins, 1/e
	Doug Young, Mountain View, California
	http://www.prenhall.com/allbooks/ptr_0132709929.html

It seems pretty decent.

A plug-in that may be useful as model is a Tcl/Tk plug-in,

	http://www.sunlabs.com/research/tcl/plugin/index.html

There are also two plug-in's available for Python
(http://www.python.org). The Oberon Juice system
(http://www.ics.uci.edu/~juice/) is also based on a plug-in.  There
are probably a number of others that can serve as models -- if you
know of any I'd like to hear about them.

There are two choices that need to be made:

	Where do the graphs get presented (and textual input/output)?

		1) In separate windows, more or less as they would be
		by a helper application.

		2) In a subregion of the browser assigned by the EMBED
		tag.

	Where does the code execute?

		A) In a separate process.

		B) In the browser process.

All four combinations are possible (as are various intermediate
positions, but I'll stick to these four). 2B is the standard design for
a plug-in, and is the hardest to implement. 1A is most un-plugin-like,
but easiest to implement, so let's start there.

1A looks very much like using XLISP-STAT or R as a helper application,
but there is an important difference: Plug-in's can allow themselves
to be controlled from Java and JavaScript, so this allows a
Java/SavaScript page to control the statistical system. The simplest
version of this would be very generic -- just start up the application
and control it with some interprocess communication mechanism --
AppleEvents on Mac, DDE or OLE Automation on Windows, X IPC or sockets
or some such on UNIX. This would require developing a protocol and
adding a little code to the application, but is fairly generic. The
same plug-in could be made to handle both XLISP-STAT and R, and lots
of other things. This is so generic, that there probably is a plug-in
available already that does this. The Hamlet system
(http://www.cs.utah.edu:80/~hamlet/hamlet/hamlet/hamlet.html) has some
of these ideas based just on an intermediate helper application -- a
starting point might be to make a plug-in that allows Java control of
Hamlet.

A slightly fancier version of 1A would be to allow the plug-in to
provide a listener window embedded in the browser that can send
commands to the statistical application and display output. Commands
could also be disabled and the window used only for output. The code
for this could be part of the plug-in (which means it would have to be
done separately for each platform) or it could be done portably in
Java. Again this is generic enough that a solution may already exist,
and if not, at least the solution can be made to work for XLISP-STAT,
R, and lots of other systems.

2A and 2B, where at least the graphics appear in the browser window,
require more thought. There two issues: design and implementation.
The design issue involves matching up the user interface model of the
statistical application with the model of the browser. For Tcl/Tk this
is fairly easy: Tk has essentially a one-window view of the
world. Usually that window is a top-level window managed by a window
manager, but having it embedded in another window is not a big step.
R currently has a two-window view: a text window and a graphics
window.  Given a rectangular region in a browser, one could allow the
region to be split into a text pane and a graphics pane by the user or
the program. XLISP-STAT is harder. It currently wants to open a new
window for everything it does. Translating that directly into a
subregion of a browser means implementing a little window manager, in
order not to be too messy. Restricting the plug-in to just one window
eliminates plot linking. It might be possible to allow multiple
plug-in instances (multiple EMBED tags in a page) to correspond to the
same XLISP-STAT process in order to support linking -- that is not in
the spirit of the Netscape plug-in model and may or may not be hard to
do -- I'm not sure. If XLISP-STAT allowed multiple graphs along with
dialogs to be placed in a single top-level window, then a single
window restriction would work -- but maybe that isn't all that
different from having a tiled mini window manager. This aspect needs
to be thougt through very carefully before jumping into the
implementation phase.

For 2A the implementation should be much easier for R -- "all" one has
to do is implement a device driver. Again it could be done natively in
the plug-in for each platform, or the plug-in could simply be a
conduit to a Java device. I am fairly sure John Chambers and Mark
Hansen have already written a Java device driver of some sort for S.
In XLISP-STAT it involves essentially the equivalent of a port to a new
window system. Again it might make sense to do the core in Java so it
is portable, but performance may be a problem. Some
performance-critical parts could be identified and be implemented as
native methods by the plug-in.

2B is the standard model for a plug-in. Following this approach allows
the plug-in to use more standard installation methods and eliminates
the need to use inter-process communication. It does potentially
involve much more work than any other approach. At a minimum it
involves making the core of the base system into a library, which is
not too hard. To be effective, it probably also requires tuning the
system to use less memory than the stand-alone systems do -- that is
more work. It would also require a careful examination of how
resources are released. For a stand-alone application this is not an
issue since the system releases all resources when the program exits
(at least it is supposed to). But a plug-in might get loaded and
unloaded many times within a session -- if it does not properly
release its resources when it is unloaded then this will eventually
bring down the browser.

One issue that affects all approaches has to do with the relationship
between different plug-in instances active at the same time. The
simplest implementation would have all plugin instances run in the
same process, which currently means they would share all global
variables.  This is not ideal since two plug-ins on a page could be
written by two different people and hence interfere with each other.
For example, each might define a function of the same name that does
different things. If XLISP-STAT or R is in a different process, then
at least on UNIX and Win32 it is possible (though wasteful) to avoid
this problem by running a separate process for each plug-in instance.
If the statistical system is run inside the browser process, then
separation is not easy. Tcl/Tk supports the idea of separate
interpreters with their own global worlds running in the same process,
so this can be handled fairly easily. XLISP-STAT currently uses masses
of global variables internally -- I think R does a bit of this
too. These would have to be moved into a single structure which can
then be replicated (at least the modifiable parts) for each plug-in
instance. With luck this could perhaps be accomplished "just" by
writing the right set of preprocessor macros, but it would take some
serious effort. On the other hand, it may also be useful at times to
allow different instances -- two plots on the same page -- to run in
the same global space in order to support linking.

Another issue is security. Automatically loading and running code from
who-knows-where is clearly dangerous -- Java has spent a lot of time
worrying about this. The plug-in should provide at least two levels of
protection. It should allow users to select the sites from which
plug-in's (either particular ones or any one) will be accepted.  It
should also allow the resources a plug-in can access to be controlled.
So for example a plug-n from the local machine might have unlimited
access, but one from outside would not be allowed to use local files
in any way. A lot has been written on this for Java
(http://www.yahoo.com/Computers_and_Internet/Programming_Languages/Java/Security/);
the Tcl plug-in developers have also thought about this quite a bit
(http://www.sunlabs.com/research/tcl/plugin/safetcl.html). Another
idea worth considering is signing plug-in code so that code with a
trusted creator can be loaded even if it is at an unknown site. The
MMM browser (http://pauillac.inria.fr/~rouaix/mmm/) does something
like this; it is probably under discussion elsewhere too.

In addition to Netscape plug-ins there are also ActiveX and OpenDoc
components. The 2B architecture would be best for supporting all
three, though a Netscape component can already be incorporated in
ActiveX and OpenDoc (though I don't know if a Java interface is
available at this time -- it probably will be before too long).

One approach to making a system more easily embeddable is to design it
around a small virtual machine and a basic run time system. The
current VM is a bit too large and too heavily entwined with the Lisp
interpreter. A good virtual machine might be able to run both Lisp and
R or S code (maybe also matlab or Gauss code) with the right
compiler. With a good design it might be possible to have several
different VM/run-time implementations, including perhaps one that uses
the Java VM. This could be useful if the JIT compiler technology
really takes off.  There is already one example of using the Java VM
for a Lisp dialect, the Kawa Scheme system (Kawa
http://www.copsol.com/kawa/index.html).

Those are some of the issues. 1A could be done fairly quickly. 2B
would, to make it a good fit, require some internal redesigning. Some
of that redesigning is a good idea anyway, like allowing multiple
graphs in a window and reorganizing the internal globals, but when it
will be done is not clear.

luke
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-testers mailing list -- For info or help, send "info" or "help",
To [un]subscribe, send "[un]subscribe"
(in the "body", not the subject !)  To: r-testers-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-