[webkit-dev] Loading from shared workers (shadow documents?)

[Drew Wilson]

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 <michaeln at google.com> wrote:

> On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson <atwilson at 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090809/60238e22/attachment.html>