[whatwg] MessagePorts in Web Workers: implementation feedback

[Maciej Stachowiak]

On May 7, 2009, at 2:47 PM, Ian Hickson wrote:

> On Thu, 7 May 2009, Drew Wilson wrote:
>>
>> Having MessagePorts in worker context means that Workers can outlive
>> their parent window(s) - I can create a worker, pass off an entangled
>> MessagePort to another window (say, to a different domain), then  
>> close
>> the original window, and the worker should stay alive. In the case of
>> WebKit, this causes some problems for things like worker-initiated
>> network requests - if workers can continue to run even though there  
>> are
>> no open windows for that origin, then it becomes problematic to  
>> perform
>> network requests (part of this is due to the architecture of WebKit
>> which requires proxying network requests to window context, but  
>> part of
>> this is just a general problem of "how do you handle things like HTTP
>> Auth when there are no open windows for that origin?")
>
> How does WebKit handle this case for regular Windows? (e.g. if a  
> script
> does x=window.open(), grabs the x.XMLHttpRequest constructor, calls
> x.close(), and then invokes the constructor.)

I believe what would happen is: the UI would be thrown up by the  
window in which the script doing x.XMLHttpRequest runs, rather than  
the home window.

  - Maciej

>
>
>> The thing we'd give up is the capabilities-based API that  
>> MessagePorts
>> provide, but I'd argue that the workaround is simple: the creating
>> window can just act as a proxy for the worker.
>
> That's a rather poor workaround. :-)
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'