> As for our implementation - I don't know how appcache is integrated with the > loader code.
We're still working out the details sans workers. But if it's a requirement to be able to a have an distinct "appache host" per shared worker, then so be it. > If not, we either need to add this support, or delay exposing appcache APIs > to SharedWorkers > until we add the ability to load data from worker context without going > through a document > object (probably required for persistent workers). I'm for deferring appcache + worker integration until we have appcach - worker integration in place (including in place for chrome). Exposing the scriptable APIs to workers don't necessarily have to go in lock step with and appcache selection and resource loading on behalf of workers. There may be some overlap with work being done to support resource loading for dedicated workers in chrome. In chrome resource loads don't go thru the renderer process at all (so no Document/Frame instances). I think Dmitry was talking about introducing a "FakeFrame" (maybe not the best name) for this purpose. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
