[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

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
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 <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>