That's a great point - we'll undoubtedly need to do something like this when we support appcache in shared workers. How hard would it be to setup a document like this? Dmitry, when you did something like this for Chromium, did you have to jump through many hoops when creating these documents? Since we use a shadow document for loading in Chromium already, do we have to do something special for dedicated workers so they inherit their parent's app cache? -atw
On Sat, Aug 8, 2009 at 7:27 PM, Michael Nordman <[email protected]> wrote: > On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson <[email protected]> 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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
