| 1 | <?xml version="1.0" encoding="UTF-8"?>
|
|---|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|---|
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|---|
| 4 | <head>
|
|---|
| 5 | <title>IcedTeaNPPlugin LiveConnect Design</title>
|
|---|
| 6 | </head>
|
|---|
| 7 | <body>
|
|---|
| 8 | <h1>IcedTeaNPPlugin LiveConnect Design</h1>
|
|---|
| 9 | <h2>Plugin Architecture</h2>
|
|---|
| 10 | <ul>
|
|---|
| 11 | <li>Divided into C++ and Java components</li>
|
|---|
| 12 | <li><ul>
|
|---|
| 13 | <li>C++ side talks to the browser</li>
|
|---|
| 14 | <li>Java side talks to the JVM</li>
|
|---|
| 15 | <li>Linked via a FIFO link</li>
|
|---|
| 16 | <li>Common string exchange format (UTF-8)</li>
|
|---|
| 17 | </ul></li>
|
|---|
| 18 | <li>Over 95% of changes in NPPlugin have been on the C++ side</li>
|
|---|
| 19 | <li>Java side has been reused as much as possible to re-use the proven stable code</li>
|
|---|
| 20 | </ul>
|
|---|
| 21 | <h2>C++ Architecture</h2>
|
|---|
| 22 | <ul>
|
|---|
| 23 | <li>Encompassing classes from the LiveConnect engine (which previously resided in Mozilla
|
|---|
| 24 | and was exposed via OJI)</li>
|
|---|
| 25 | <li>Each JavaScript var corresponding to a Java object has a corresponding
|
|---|
| 26 | <code>IcedTeaScriptableJavaObject</code></li>
|
|---|
| 27 | <li>Engine controls the object life and services all requests (get field, set field,
|
|---|
| 28 | invoke method, etc.)</li>
|
|---|
| 29 | </ul>
|
|---|
| 30 | <h2>C++ Architecture (Browser Interface)</h2>
|
|---|
| 31 | <ul>
|
|---|
| 32 | <li>Browser interface consists primarily of <code>IcedTeaScriptableJavaPackageObject</code>,
|
|---|
| 33 | <code>IcedTeaScriptableJavaObject</code> and <code>IcedTeaPluginRequestProcessor</code>.</li>
|
|---|
| 34 | <li>Above classes are unaware of Java interactions and delegate to the Java interfaces
|
|---|
| 35 | for Java interaction.</li>
|
|---|
| 36 | <li>They process all requests coming from the browser and going to the browser (<code>getMember</code>,
|
|---|
| 37 | <code>call</code>, <code>eval</code>, etc.)</li>
|
|---|
| 38 | </ul>
|
|---|
| 39 | <h2>C++ Architecture (Java Interface)</h2>
|
|---|
| 40 | <ul>
|
|---|
| 41 | <li>Java interface consists primarily of <code>IcedTeaJavaRequestProcessor</code>.</li>
|
|---|
| 42 | <li>This class has full knowledge of how the Java side works, and constructs appropriate
|
|---|
| 43 | requests to get all information from Java.</li>
|
|---|
| 44 | <li>The class processes all requests to the JVM.</li>
|
|---|
| 45 | </ul>
|
|---|
| 46 | <h2>Java Architecture</h2>
|
|---|
| 47 | <ul>
|
|---|
| 48 | <li>Java side has two core classes aside from helpers: <code>PluginAppletViewer</code>
|
|---|
| 49 | and <code>PluginAppletSecurityContext</code>.</li>
|
|---|
| 50 | <li><code>PluginAppletViewer</code> is an interface to NetX and processes JS-related
|
|---|
| 51 | requests to and from NetX (the applet).</li>
|
|---|
| 52 | <li><code>PluginAppletSecurityContext</code> is a direct reflection-based interface
|
|---|
| 53 | to the VM. It processes all LiveConnect requests to and from the JVM.</li>
|
|---|
| 54 | <li>Request processing is asynchronous, with scalable generic request processing workers.</li>
|
|---|
| 55 | </ul>
|
|---|
| 56 | <h2>Java Architecture (<code>PluginAppletViewer</code>)</h2>
|
|---|
| 57 | <ul>
|
|---|
| 58 | <li>Control of applet (initialize, resize, destroy, etc.) from browser.</li>
|
|---|
| 59 | <li>Access to JavaScript from the applet (<code>getMember</code>, <code>setMember</code>,
|
|---|
| 60 | <code>call</code>, <code>eval</code>, etc.)</li>
|
|---|
| 61 | </ul>
|
|---|
| 62 | <h2>Java Architecture (<code>PluginAppletSecurityContext</code>)</h2>
|
|---|
| 63 | <ul>
|
|---|
| 64 | <li>Direct access to the JVM from the browser (LiveConnect) via reflection.</li>
|
|---|
| 65 | <li>All reflection is built-in, so C++ side never needs to be aware of the complexities,
|
|---|
| 66 | unlike how OJI was.</li>
|
|---|
| 67 | <li>All VM calls are inside a sandbox, so JavaScript can not do things that the default
|
|---|
| 68 | sandboxed VM can't.</li>
|
|---|
| 69 | </ul>
|
|---|
| 70 | <h2>MessageBus Architecture (C++)</h2>
|
|---|
| 71 | <ul>
|
|---|
| 72 | <li>The link to Java is exposed to the rest of the code via a uniform "MessageBus" interface.</li>
|
|---|
| 73 | <li>Since the code is unaware of the link specifics and has no synchronicity guarantee, the communication
|
|---|
| 74 | medium can be switched relatively easily.</li>
|
|---|
| 75 | <li>Classes interested in the messages implement a <code>BusSubscriber</code> class and subscribe to
|
|---|
| 76 | the bus of interest.</li>
|
|---|
| 77 | <li>When messages come in, the bus notifies all subscribers.</li>
|
|---|
| 78 | </ul>
|
|---|
| 79 | <h2>Example JS->Java Workflow</h2>
|
|---|
| 80 | <ul>
|
|---|
| 81 | <li>Example shows how <code>NPP_HasProperty()</code> works</li>
|
|---|
| 82 | <li>Browser has a link to an <code>IcedTeaScriptableJavaObject</code> representing a Java
|
|---|
| 83 | object instance.</li>
|
|---|
| 84 | <li>It call <code>IcedTeaScriptableJavaObject::HasProperty()</code></li>
|
|---|
| 85 | <li><code>HasProperty()</code> creates an <code>IcedTeaJavaRequestProcessor</code>
|
|---|
| 86 | ("Java processor")</li>
|
|---|
| 87 | <li>The Java processor exposes all necessary APIs to the VM, including <code>hasProperty</code>
|
|---|
| 88 | (called <code>hasField</code> for Java naming consistency).</li>
|
|---|
| 89 | <li>Before making a <code>hasField</code> request, the processor subscribes itself
|
|---|
| 90 | to the "from Java" bus, so that it can read the response.</li>
|
|---|
| 91 | <li>The <code>hasField</code> request is made by the processor and posted to the
|
|---|
| 92 | "to Java" bus.</li>
|
|---|
| 93 | <li>The processor waits for either a response or a timeout.</li>
|
|---|
| 94 | <li>Once a response is received, the processor unsubscribes itself from the
|
|---|
| 95 | "from Java" bus, performs post-processing and returns.</li>
|
|---|
| 96 | <li>The <code>IcedTeaScriptableJavaObject</code> object reads the response and
|
|---|
| 97 | sends it to the browser.</li>
|
|---|
| 98 | </ul>
|
|---|
| 99 | <h2>Example Java->JS Workflow</h2>
|
|---|
| 100 | <ul>
|
|---|
| 101 | <li>All access to JS is via <code>JSObject</code> instances as defined in the
|
|---|
| 102 | LiveConnect specification.</li>
|
|---|
| 103 | <li>If an applet wants to access a member of <code>JSObject</code>, "window"
|
|---|
| 104 | for example, it will call <code>getMember</code> on the window's <code>JSObject</code>.</li>
|
|---|
| 105 | <li><code>getMember</code> calls a similarly named function in
|
|---|
| 106 | <code>PluginAppletViewer</code>.</li>
|
|---|
| 107 | <li><code>PluginAppletViewer</code> constructs a request for the C++ side and
|
|---|
| 108 | posts it on the FIFO link.</li>
|
|---|
| 109 | <li>On the C++ side, <code>IcedTeaPluginRequestProcessor</code> (the plugin
|
|---|
| 110 | processor) is always subscribed to the "from Java" bus.</li>
|
|---|
| 111 | <li>When the <code>getMember</code> request comes through, the plugin processor
|
|---|
| 112 | gets notified.</li>
|
|---|
| 113 | <li>The embedded request</li>
|
|---|
| 114 | </ul>
|
|---|
| 115 | </body>
|
|---|
| 116 | </html>
|
|---|
| 117 |
|
|---|