And doing continuation transformations for loop constructs is extra difficult.
One possibility is to just use Rhino/HtmlUnit for everything and proxy
all browser API calls, not to an emulated DOM, but do C++ DOM IDL
bindings. This is sort of like Python-WebKit/Pyjamas. So we don't
emulate the entire browser, we just replace it's Javascript execution
engine with Rhino.
e.g.
// Runs in JVM
public void foo() {
bar();
}
// Runs in JVM using Rhino
public native void bar() /*-{
$doc.body.innerHTML = "foo"; // $doc is proxy, .body returns proxy,
.innerHTML = "foo" invokes native C++ binding to set inner html
}-*/;
This could be problematic for some APIs like IndexDB which rely on
script context / event loop termination to know when to "commit" a
transaction but we could probably find workarounds. Also,
order-of-operations might be different. Most DOM ops in JS occur
within the event loop and the browser may be able to batch their
effects unless they are demanded (e.g. element.offsetHeight triggering
layout). With the C++ bindings, I'm not sure what kind of control
over the event loop you have. Given that Rhino lives in a separate JVM
thread, we'd need to be able to make sure that when the Rhino code is
running, the browser event loop can't run, etc.
Lots of details and I'm sure it would break some backwards
compatibility, but would probably have nice performance improvements.
-Ray
On Thu, Sep 15, 2011 at 11:52 AM, John Tamplin <[email protected]> wrote:
> On Thu, Sep 15, 2011 at 2:44 PM, Marcin Wiśnicki <[email protected]>
> wrote:
>>
>> Is this blocking strictly necessary or would it suffice to simulate it
>> with continuation passing ?
>
> The problem is the original call site is written as a blocking call, and
> ultimately may have originated from Java. Ie:
> void foo() {
> x = bar();
> }
> native int bar() /*-{
> var x = @Foo::baz()();
> return 2 * x;
> }
> int baz() {
> return 42;
> }
> Sure, you might could theoretically rewrite bar to pass a continuation to
> baz, but baz is Java code, so you would have to rewrite that as well as
> anything it calls, which may include JRE code. Then that passes the other
> way as foo() has to know that bar doesn't return the value directly.
> I really don't think this is feasible.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
