[webkit-dev] SharedWorkers alternate design

Michael Nordman michaeln at google.com
Wed Jun 17 18:23:47 PDT 2009

On Wed, Jun 17, 2009 at 3:43 PM, Drew Wilson <atwilson at 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

> 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 <michaeln at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090617/9c60eb67/attachment.html>

More information about the webkit-dev mailing list