summaryrefslogtreecommitdiff
path: root/tests/FunctionalTests/selenium/doc/jsrmi.html
diff options
context:
space:
mode:
authorwei <>2006-05-31 04:37:17 +0000
committerwei <>2006-05-31 04:37:17 +0000
commit1fcb71a6a18e332eb6410b85aa8b812795087c08 (patch)
tree77091f2a174a2306913eb9d9e06a15dde9fdfd8f /tests/FunctionalTests/selenium/doc/jsrmi.html
parent3ac04dd9cbb3c14fb2522793b2268b910837d8c4 (diff)
Remove old selenium.
Diffstat (limited to 'tests/FunctionalTests/selenium/doc/jsrmi.html')
-rw-r--r--tests/FunctionalTests/selenium/doc/jsrmi.html151
1 files changed, 0 insertions, 151 deletions
diff --git a/tests/FunctionalTests/selenium/doc/jsrmi.html b/tests/FunctionalTests/selenium/doc/jsrmi.html
deleted file mode 100644
index 035f4a4e..00000000
--- a/tests/FunctionalTests/selenium/doc/jsrmi.html
+++ /dev/null
@@ -1,151 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>JSRMI</title>
-</head>
-<body>
-<p>JSRMI (Javascript Remote Method Invocation) is a portable browser-neutral Javascript library that makes it possible to execute
-Javascript functions in a browser from a process external to the browser.</p>
-<p>JSRMI is not in any way tied to Java's RMI, but provides a similar mechanism. JSRMI is completely decoupled from the core Selenium Javascript API, but it can
-be used to access the Selenium API from outside the browser. </p>
-<p>All of the
-browser-side JSRMI code resides in the rmi.js script - available in the Selenium
-distribution.</p>
-<h2>Browser support</h2>
-<ul>
- <li>IE 5</li>
- <li>Mozilla 1</li>
- <li>Netscape 7</li>
- <li>Firefox 0.92</li>
- <li>Safari 1.2</li>
-</ul>
-<h2>Language support</h2>
-<ul>
- <li>Ruby</li>
-</ul>
-<p>Libraries for other languages are under way.</p>
-<h1>How do I use JSRMI from an external process?</h1>
-<h2>Ruby</h2>
-<p>Just include the jsrmi script in your own:</p>
-<p><font face="Courier New">require &quot;jsrmi&quot;<br>
-<br>
-browser = Selenium::Browser.new.proxy<br>
-someArea = browser.document.getElementById(&quot;someArea&quot;)<br>
-someArea.value = &quot;Hello from Ruby #{Time.new}&quot;</font></p>
-<p>This will modify the text of a text area in the browser. Looks strangely
-familiar to Javascript doesn't it? You can of course call the selenium API too
-if the browser has loaded the main Selenium page (which also includes the rmi.js
-script - at least that is the plan - I hope (Aslak)).</p>
-<h1>How does it work?</h1>
-<p>(You can safely skip this section if you don't care - this is gory details)</p>
-<h2>Browser side</h2>
-<p>The rmi.js script uses the
-<a href="http://developer.apple.com/internet/webcontent/xmlhttpreq.html">
-XMLHttpRequest</a> object (available in all compatible browsers) to communicate
-with the external process. It executes a GET-POST loop which is repeated ad
-infinitum - pulling JSRMI invocations from the external process with GET and
-POSTing the results back. This all happens in a separate thread, thereby having
-minimal impact on the rest of the web page - without causing a page refresh.</p>
-<p>The rmi.js script will do a HTTP GET to a URL on the same host/port as the rmi.js
-script was loaded from. The content returned from the GET (which must comply
-with the <a href="#protocol">JSRMI protocol</a>) is then translated into
-Javascript and dynamically executed via Javascript's <font face="Courier New">
-eval()</font> function.</p>
-<p>The result of the function call (typically a Javascript object) is translated
-back into the JSRMI protocol format and POSTed back to the same URL as the GET.</p>
-<h2>External process side</h2>
-<p>The external process typically consists of a library that embeds the
-following functionality:</p>
-<ul>
- <li>A HTTP server (should be light to ensure fast startup)</li>
- <li>An API that translates local invocations into the JSRMI protocol</li>
- <li>Two blocking queues:</li>
- <ul>
- <li>Output queue - HTTP GET invocations will take JSRMI protocol strings
- (representing browser side invocations) from this queue and block until
- something is available. These strings are returned to the HTTP client (The
- rmi.js script in the browser). This means a blocking GET for the JSRMI
- browser side).</li>
- <li>Input queue - HTTP POST data from the browser side JSRMI will be enqued
- here. This data represents results of browser side Javascript invocations.</li>
- </ul>
-</ul>
-<p>A local invocation should translate the invocation to a JSRMI protocol string
-and put it on the output queue (which jsrmi will GET). It should then wait for
-the result of the browser side invocation to be put back on the input queue via
-a POST from jsrmi. Finally it should translate the return value (another JSRMI
-protocol string) into a native object and return it to the caller.</p>
-<p>At any given point in time there should only be one single JSRMI protocol
-string in one of the queues - depending on the where the invocation is in its
-lifecycle.</p>
-<h2>Reference objects</h2>
-<p>JSRMI allows objects (such as browser side HTMLDocument, HTMLTextField etc)
-to be transferred back and forth. This is based on a simple mechanism where each
-object is given a unique id and maintained in a pool on each side. this pool is
-used to reference and dereference native objects back and forth from the JSRMI
-protocol strings.</p>
-<h1>Why would I use JSRMI?</h1>
-<h2>With Selenium</h2>
-<p>The Selenium browser runtime will load both selenium test scripts and the web
-pages from the web application you're testing into the browser. Modern browsers
-don't allow content to be loaded from different hosts (cross browsing security
-restrictions). A web application being tested will typically be deployed on a
-server, and therefore the selenium test scripts must be loaded from the same web
-server. Depending on who's writing the Selenium scripts and executing them, this
-may or may not be a restriction to its usage.</p>
-<p>Under some circumstances it is desirable to keep Selenium test scripts on
-your local machine (the same as the one running the browser with the Selenium
-runtime) rather than on a remote web server hosting the web application being
-tested. Some examples are:</p>
-<ul>
- <li>The edit/run cycle of selenium scripts can be cumbersome if the script has
- to be deployed to a server each time it is modified. Being able to keep the
- scripts on a different machine (such as the one on your desk) can
- significantly improve the ease of use and rapid development of tests. JSRMI
- lets you do just that.</li>
- <li>Putting in place a deployment routine for selenium script requires
- technical knowledge of the web application's build process as well as the web
- server hosting it. Many users of Selenium will not have easy access to this
- expertise. JSRMI lets these users use Selenium nevertheless.</li>
-</ul>
-<p><i>It is important to emphasise that hosting the Selenium scripts on a local
-machine would also require that the browser loads the web site being tested from
-the local machine. Aren't we creating new problems by requiring testers to
-install a full web server environment on their machines? Actually no. The JSRMI
-libraries in Ruby and Java (and those who may follow) will soon provide a light
-HTTP proxy server. The local browser will load the remote web site through this
-HTTP proxy. The browser's security restrictions are satisfied since all content
-(Selenium runtime, Selenium scripts and the remote website) is loaded through
-localhost.</i></p>
-<h2>Scripting of existing web applications</h2>
-<p>Think of all boring web form tasks you could automate with JSRMI....</p>
-<h1><a name="protocol">The JSRMI protocol</a></h1>
-<p>TODO: describe the format.</p>
-<h1>How do I implement a JSRMI client library for language X?</h1>
-<p>Start by understand the inner workings - look at the ruby implementation and
-study the javascript. (When the JSRMI protocol is better described, studying
-this code should not be necessary). </p>
-<p>It will be to implement a JSRMI client
-library in a dynamic language than a static language, because dynamic languages
-allow arbitrary messages (method invocations) to be sent to an object. Most
-dynamic languages (Ruby, Python, Groovy, Smalltalk) have a generic mechanism to
-intercept any message and an object message-&gt;JSRMI protocol translation logic is
-trivial to implement based on this.</p>
-<h2>Guidelines for static languages such as Java and C#</h2>
-<p>JSRMI clients for static languages such as Java or C# will either have to
-choose a subset of the Javascript functions and objects that you want to access,
-or implement some generic invocation mechanism that allows raw JSRMI protocol
-strings.</p>
-<p>The former is more easy to use from a user perspective, but will be
-restricted in terms of flexibility. The latter is completely generic, but
-awkward to deal with from a user perspective.</p>
-<p>The recommendation is to implement a raw interface to the JSRMI protocol and
-have a generic dynamic proxy implementation on top of that. This way the API
-support can easily be extended simply by implementing new interfaces for the
-Javascript counterparts and generate dynamic proxies on the fly as needed. </p>
-<h2>Calling functions/methods in an external process from the browser using JSRMI</h2>
-<p>This is currently not possible.</p>
-</body>
-</html> \ No newline at end of file