[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

2009/6/2 Alexey Proskuryakov <ap at webkit.org>:
>
> From Andrew's design document, I don't see how my description was
> inaccurate:
>
> ---------------------------
> Currently, all worker XHR requests are proxied to the parent page and
> executed on the main thread. This approach currently works for dedicated
> workers because there is a 1:1 mapping between dedicated workers and active
> pages, and the worker is shutdown when the page closes. For SharedWorkers
> (and for dedicated workers once we introduce nested workers) this is no
> longer the case - the worker can outlive the parent page.
>
> To address this, we will use the DocumentSet for the worker. Worker XHR
> requests will still be proxied to the main thread. This task will request
> the DocumentSet from the repository, and select a document from that set to
> use to satisfy the request. If the DocumentSet is empty, then it means that
> the worker is shutting down, so the XHR should return a failure response.
> ---------------------------
>
> From my reading of this, it appears that shared workers will use FrameLoader
> of the opener page, or some other page in the DocumentSet, and won't get
> their own loaders (that would be a feature of persistent workers, which we
> aren't even discussing yet). This speaks specifically about XHR, but I
> assumed that the same holds true for other network requests.

That would be a design flaw... not a feature. All of this stuff about
the DocumentSet associated with a shared worker is a hack to work
around the problem of "how to load resource without a frame in
webkit".

Per the spec, shared workers are a distinct "browsing context". In
appcache terms, they have a distinct "appcache host". We have to come
up with a design that accomplishes that.



>
> - WBR, Alexey Proskuryakov
>
>
> 02.06.2009, в 21:18, Michael Nordman написал(а):
>
>>> When a document calls a SharedWorker constructor, the worker script is
>>> loaded from the document's
>>> appcache (because all subresource loading goes through appcache, of
>>> course).
>>
>> If I understand correctly, that is not what the spec currently says.
>>
>> Dedicated workers load as you describe, but not shared workers. The
>> algorithm to determine what resource to load for a shared worker is
>> the same as the algorithm used to determine what resource to load for
>> a window.open(urlToPageWithoutAManifestAttributre) call.
>>
>> Personally, I think we should defer adding support for the appcache
>> scriptable API to workers for the time being. But do support the
>> resource loading / cache selection as currently specified. This would
>> allow shared workers can be versioned independently (despite not
>> having a good reload worker after an update story).
>>
>> These are shared workers. That implies a degree of separation from the
>> pages that are sharing them.
>
>
>
>