On Wed, Jun 17, 2009 at 3:43 PM, Drew Wilson <atwil...@google.com> wrote:
> Following up again on this - now that my cross-thread MessagePort patch is > getting close to landing, I am moving forward on the SharedWorker design > described earlier in this thread. > I think there is still little clarity around the appcache behavior (dimich: > are you bring over your "shadow frame" concept to webkit?). > I think we're making decent progress, but integration with workers is a ways off yet. First things first for me, get things working w/o workers. I'm wondering about bringing the 'shadow frame' technique to webcore too? > > It doesn't seem like it should block the rest of SharedWorker development > while we work out the details - I will not expose the appcache APIs for > SharedWorkers until we have consensus about how they should work. > Sounds good. You should plow ahead without concern for appcache integration. I'll back fill later. We'll have similar backfilling to do with the Database too. > > > Let me know if you have any concerns with my approach. I'll add an > ENABLE_SHARED_WORKERS flag to control access to these APIs while development > proceeds. > > -atw > > > On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman <micha...@google.com>wrote: > >> > 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
