RE: Workers

Reading through this response, Maciej's response from a few weeks ago, and
the revised spec, I see that my previous questions/comments are mostly
irrelevant, since I overlooked the part in the initial draft about this
being a message passing system.

I think that you would be much happier with just making a async version of
eval() which "jails" itself:

function RemoteScriptExample(scriptURL) {
   evalAsync("eval(downloadMethod(scriptURL));");
}

function LocalScriptExample {
   evalAync("//Do stuff asynchronously here");
}

The way that I can see this being implemented with maximum grace & backwards
compatibility, is to ask the ECMAScript folks to add evalAsync() to
ECMAScript. That spec would consider any method/interface to be forbidden
from being accessed in an evalAsync() method, unless explicitly permitted in
the object model with some sort of flag (or the other way around, whichever
makes the most sense). We then add the correct flags to the HTML DOM as
appropriate.

The reason why I suggest this is that is carries a degree of simplicity be
leveraging existing knowledge. Adding evalAsync() to one's understanding is
a lot easier, in my mind, than a whole new object with specific rules,
parameters, etc. It also allows for a script to self-store (and even
on-the-fly generate) the worker's code as opposed to relying upon an
external source for it as the current proposal seems to. The simple "recipe"
in RemoteScriptExample() shows that it is trivial for authors to do what the
current draft does too, in very little code.

Just an idea, sparked by the major shortcoming of the current proposal,
which is the inability for scripts to self-store or generate on-the-fly the
code for the WindowWorker to execute.

J.Ja

Received on Friday, 18 July 2008 14:17:45 UTC