[webkit-dev] SharedWorkers alternate design

John Abd-El-Malek jam at google.com
Mon May 25 22:41:37 PDT 2009


On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Fri, May 22, 2009 at 2:25 PM, Drew Wilson <atwilson at google.com> wrote:
>
>> 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,
>
>
> This is the gist of what I'm planning for LocalStorage and I believe what
> Michael's planning for AppCache.  At least in my case, I think I'll be able
> to share a substantial amount of code by running the backend of the code in
> the chromium browser process.
>

I also agree this is the cleanest approach.  Especially for these kind of
objects (workers, storage) that aren't created or called that frequently,
the memory and performance overhead is negligible.  One other benefit is
that it allows platforms to both define their own implementations and to use
the default WebKit implementation.

>
>
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090525/7cc9b837/attachment.html>


More information about the webkit-dev mailing list