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

[Michael Nordman]

Regarding "something special" for dedicated workers, the worker system will
have to initialize the ApplicationCacheHost associated with the shadow doc
specifically for a dedicated worker to know who the parent is (two integer
values, parent processID + cacheHostID). Beyond that, the appcache system
will be able to handle the differences (which should amount to very little).
We can look at that after the appcache related webkit API mods are landed
(which should happen this week).

On Sun, Aug 9, 2009 at 8:33 AM, Drew Wilson <atwilson at google.com> wrote:

> 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/831e0d8c/attachment.html>