[webkit-dev] SharedWorkers alternate design

Drew Wilson atwilson at google.com
Fri May 22 14:25:53 PDT 2009


Following up on this, I had a question about the best way to enable the
implementation of SharedWorkerRepository to vary for different platforms.
I'd like to provide a default WebKit implementation, but on Chromium we'll
want to provide an implementation that proxies shared worker operations to
the browser process - it is unlikely that the two implementations will share
very much (any?) code.

The current design just defines SharedWorkerRepository as an interface, then
has a platform-specific static factory which returns an instance of this
class - the idea is that I'd provide a default WebKit implementation (called
SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want
their own implementation) can provide their own factory method and
implementation (for an example of this, see WorkerContextProxy::create() in
WebCore/worker/WorkerMessagingProxy.cpp.

Is this an acceptable approach? Other approaches I've seen either scatter
ifdefs around in header files (see KURL.h for an example) which seems
non-ideal for our case which won't have any shared code, or to have separate
platform-specific subdirectories, but I'm not certain what the naming
convention is for a directory that contains "<implementation for everything
but chromium>".

I think the interface + static factory approach is the cleanest, but I've
gotten the impression that the use of virtual functions to vary
implementations per-platform is frowned upon in WebKit. Any advice for me?

-atw



On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen <
kenneth.christiansen at openbossa.org> wrote:

> I believe Qt uses instance() in this situation.
>
> > Sadly we have not yet found a good verb for the common "get or create"
> > idiom.
>
> Cheers.
> Kenneth
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090522/ec643fbf/attachment.html>


More information about the webkit-dev mailing list