Duncan Temple Lang

Jan/ 2001

Table of Contents

  1. Basics
    1. Future Features
      1. Security

        Abstract

        The idea is to run S within the user's browser. We can then exploit this S engine in several different ways. URLs containing S scripts can be loaded from a server (identified with a special mime-type) and the code locally within the browser evaluated to create the entire document. Additionlly, we can use the S engine to create interactive and dynamic plots as embedded components/objects within an HTML page. Here, the author provides an area within the document and the S commands to create the plot. A collection of different event handlers can be specified for the plot, giving a richer style of interaction currently possible within R. Finally, and most flexibly, we can use S as an extension of JavaScript, providing access within JavaScript code to the different S functions and also allowing S to access variables created in JavaScript, Java and other plug-ins. In some respects, this style is very similar to the inter-language interfaces for Perl, Python and Java already developed for S. Also, it is a rich example of the component-oriented focus of Omegahat in which the author can chose to program in any of several different langauges and access the objects and functionality in each of the others.

        Evaluating "fixed" S scripts within each browser is a waste of resources. It can be done just once on the server and the resulting (HTML) document downloaded directly by the client. Where the plug-in adds value is when we have an HTML document that contains dynamic content. Suppose we have an HTML form which allows users to type S expressions and see the output within the browser. We can then add (JavaScript) event handlers to elements in the form (e.g. radio buttons) and have these handlers update the S output. Additionally, we can add Java components that provide us with different graphical interface elements and again, connect these to the S engine to update the displays. Finally, we can develop a browser device-driver so that S graphics are displayed within an HTML page. This can also respond to user actions in new ways. The HTML document can be generated from an XML document that contains S code and from which we generate an HTML document by executing that code and substituting the output in its place.

        We use the browser to provide the formatting and the dynamic components. We use the S engine to supply (some of) the dynamic content. This provides functionality that is available in via Rweb and Rcgi. However, these require lengthy trips to a server; they do not provide interactive components; and those models do not support dynamic content tied to interactive components.

        1. Basics

        The key idea is that we want to be able to produce live documents. These are not just dynamically created documents which can be created on the server and shipped as a fixed HTML document. We can use the S in Xalan facility for this. We do also want to be able to support performing these computations on the client side to simplify security, persistence and resource allocation issues.

        Instead, we are talking about documents whose contents can be updated during the lifetime of that document. These include elements within a document such as an interactive plot, dynamically generated output , for example a table associated with a Java slider or that is updated at frequent intervals.

        One approach to creating dynamic elements is to put them in their own frame. Then, we can use a special MIME type to associate the contents of the frame with the S plugin and have it generate the content of the frame.

        For plots, we can use the EMBED or OBJECT tag and associate these instances with an S graphics plugin that handles plots.

        For dynamic text, we want to be able to execute code to create the text. This would work just as with JavaScript. One way to arrange this is to provide a method invocation mechanism from JavaScript. We allow the R functions to return strings which can be included in the HTML being created.

        One way to use this plugin is to take a script and in addition to having entire documents (i.e. the contents of a frame) Using JavaScript, Java and LiveConnect we can communicate with the different components and write the controlling programs in any of these languages. Additionally, we can use Tcl/Tk to define components and interact with those in the same way from within S, Java, JavaScript, etc.

        Note that we have already done this in TILE with our "browser". The Dynamic Text Substitution module in that distribution traverses the HTML/XML tree and evaluates code sections in much the same way JavaScript operates.

        2. Future Features

      2. S Functions in JavaScript
        3. It would be nice to export functions automatically from R to JavaScript so that they could be called within JavaScript code something like 
          s.exists("rnorm")
  s.attach()
  s.library()
  s.lm();
        We can do this by adding Java entry points for this. However, we would like to do it dynamically, i.e. on demand lookup and resolution. Also, handling packages/namespaces is important.
      3. Calling JavaScript from S
        4. This is relatively easy, especially with the Java package that we currently have. We just bring in JSObjects as anonymous references and work with these from R.
      4. S.call()
      5. Complex Converters
        6. To and from S.
      6. JavaScript Functions
        7. Use JavaScript functions as Java methods. Same trick as using S functions as Java methods.
      7. Accessing Netscape Data and Routines

        8. 3. Security

        Query when loading a shared library. Change definition of system, unlink, Another good reason not to use files to store intermediate output (e.g. sink(x); print(foo); sink(); scan(x)). Allow ouptut to text connections, or handlers!