RE: Workers

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