On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson <atwilson@google.com> wrote:
Hi all, I'm about to work on adding network access support to shared workers. To refresh your memory, shared workers can outlive any specific document object - they exit when the last referring document exits.
Current dedicated workers just proxy all network operations over to their associated Document object. If the Document is closed prematurely, then the network operation is aborted and an error is returned to the worker, which is fine because the Worker is exiting anyway.
For shared workers we can't just proxy network operations over to an arbitrary parent document, because the user may choose to close that document in mid-load yielding an inappropriate error response to the user. We have a few options:
1) If a document closes mid-load, just return an error to the worker. So treat this case like Just Another Network Hiccup.
2) If a document closes mid-load, just retry the network access on another parent document. I'm not certain that this is acceptable from a spec-compliance standpoint (the server might end up seeing multiple network requests even though from the client stand point only one was issued).
3) Don't let documents fully go away while there's outstanding worker network access. For a long-lived hanging get, this seems like it might keep a document around (in hidden state) for a long time, and I'm not sure what the ramifications are of that. Also, there's the issue of how to deal with things like HTTP auth from hidden documents (although HTTP auth is problematic for shared workers in general as it's kind of arbitrary which window the auth UI appears under).
4) Create a new "shadow document" for the worker that it uses to satisfy all of its loading requests. This is what Chromium does for all its worker network access currently. This is the most robust solution, although I'm still not certain how HTTP auth would be handled in this case).
#4 seems like the most sensible option long term. * Solves the bug around spurious failures when the parent goes away at just the wrong time. * Avoids some appcache related complications. A shared worker can be associated with an appcache that is all its own. It may be that none of the parent documents are associated with the same appcache (or any appcache). That situation seems like a recipe for awkward special cases in the loader to delegate to the 'right' appcachehost when its processing a request on behalf of a shared worker. Where to surface UI related to a shared worker's request is a good question. Maybe a shared workers requests shouldn't present UI for HTTPauth or SSL related prompts, anything that would require user intervention could just fail w/o leaving any traces (we'd have to be careful to distinguish these kind of failures from explicit user cancels when it came to the validity state associated with the SSL cert).
I'm leaning towards #1 in the short-term, but I'd like to get feedback about what our long-term approach should be.
-atw
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev