[webkit-dev] SharedWorkers alternate design

[Sam Weinig]

On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <jam at google.com> wrote:

> I agree that this approach is powerful.  However there are (not too
> frequent) situations when a port like Chromium wants to use both the WebKit
> implementation and its own implementation, switching in runtime.  For
> workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
> the interfaces that a worker object implements/uses.  Since workers run in a
> separate process from the renderer, we use our own implementations of these
> interfaces that know about IPC etc.  However once we're in the worker
> process, we want to run nested workers in the same process, in which case we
> want to use the WebKit implementation of these interfaces directly without
> using Chromium's.


This doesn't seem like a runtime choice, but rather a "use-time" choice.  In
the main context, you want use one implementation and in the worker context,
another one.  This to me implies two different objects with different names.
 In non-multiprocess implementations of WebKit, these two objects could be
the same object, and in multiprocess implementations (such as Chromium),
they could be backed by different objects.  This would not incur a runtime
cost (and would be, subjectively of course, clearer).

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/5d089e27/attachment.html>