- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 18 Jul 2008 21:14:02 +0000 (UTC)
- To: Justin James <j_james@mindspring.com>
- Cc: public-html@w3.org
On Fri, 18 Jul 2008, Justin James wrote: > > 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"); > } How would you communicate with such a mechanism? In general, the Gears team found that people much prefer just giving a URL than giving a string, so it would be: evalAsync(url); ...which if fundamentally no different than what the spec does: createWorker(url); ...except that the spec returns a message port: var port = createWorker(url); > 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. I don't really mind which spec we put it in. Would you like to propose this to the ECMAScript committee? (I don't really have the bandwidth to join another group as well.) > 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. There's no new object for workers in this proposal, actually, from the caller side. In fact, as far as I can tell what the current Workers spec does and what you propose are identical modulo the method name, as shown above. > 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. In practice experience shows that people prefer URLs to strings here. If you really want to generate your own code, then you can use data: URLs. > 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. Why is this a major shortcoming? I haven't heard of any use cases for why this would be necessary. Unless this is something that is commonly done -- and the Gears team's experience suggests it is not -- it seems like data: URLs are enough for this. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 18 July 2008 21:14:41 UTC