[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

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?).

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.

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/1fd469d9/attachment.html>