[whatwg] MessagePorts in Web Workers: implementation feedback

[Ian Hickson]

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.)


> 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.   `._.-(,_..'--(,_..'`-.;.'