[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

OK, I've got two strong votes for the interface + static factory approach.
Any objections from the rest of the WebKit team? If I don't hear any counter
proposals, I'll do that.

-atw

On Mon, May 25, 2009 at 10:41 PM, John Abd-El-Malek <jam at google.com> wrote:

>
>
> 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/20090526/edfb4972/attachment.html>