[whatwg] MessagePorts in Web Workers: implementation feedback

[Drew Wilson]

It looks like WebKit binds the XMLHttpRequest object to its parent document
at instantiation time, so the source of the constructor doesn't make a
difference. And it looks like that binding is cleared when the document is
closed so invoking xhr.send() on an XHR object whose parent document is no
longer open fails silently. I'm basing this on code inspection, not on
extensive knowledge of the codebase, so the webkit folks should feel free to
correct me here.

Why is having the window proxy on behalf of its workers a poor workaround
for worker MessagePorts? I totally understand the utility of MessagePorts
for things like cross-window and cross-iframe communication, but it seems
like the use cases for external access to workers are far more obscure.

-atw

On Thu, May 7, 2009 at 2:47 PM, Ian Hickson <ian at hixie.ch> 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.)
>
>
> > 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.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090507/adabb0c9/attachment.htm>