2009/6/2 Alexey Proskuryakov <a...@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. > > > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev