On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <j...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
