[whatwg] MessagePorts in Web Workers: implementation feedback
Ian Hickson
ian at hixie.ch
Thu May 7 14:47:04 PDT 2009
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list