- From: Justin James <j_james@mindspring.com>
- Date: Fri, 18 Jul 2008 10:16:20 -0400
- To: "'Ian Hickson'" <ian@hixie.ch>, <public-html@w3.org>
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