[webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>>
>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org>wrote:
>>>
>>>> The common case is definitely that we know whether we want the proxy
>>>> (for IPC) or the implementation at compile time.  In some cases (like
>>>> Chromium) this is not known until initialization time.
>>>
>>>
>>>  What do you mean by "initialization time"?  Is it the case that you know
>>> which one you want at each call site?  Or do literally want to make a
>>> runtime choice based on state?
>>>
>>
>> Well, I meant that we always want one or the other based on if the process
>> is being used as a render process (i.e. sandboxed, running WebKit but with
>> all DOM Storage calls proxied) or a browser process (i.e. running only
>> selected parts of WebCore like the DOM Storage backend/implementation).
>>
>>
>> Come to think of it (IIRC) all calls to the StorageBackend within the
>> WebCore code should go through a proxy for Chromium.  The proxy will then
>> call into Chromium's webkit bridge/glue, which will pass the message through
>> the IPC layer, which will call back into bridge/glue code, which will be
>> interacting with the real implementation.
>>
>> If that's true, then the implementation could be very explicitly split
>> into 2 (with frontend code calling backend proxy code and vice versa) and
>> single process implementations could simply typedef _____Proxy to _____Impl
>> (or Implementation, or Base, or whatever you want to call it).
>>
>> ....or have I completely confused myself?
>>
>
> To clarify, I'm saying that your question made me realize that we probably
> can make a hard split between the frontend and backend code (i.e. what would
> live in a sandbox and handle page rendering and what wouldn't live in a sand
> box and store the actual DOM Storage data).  In single process cases where
> there is no IPC barrier, and thus no proxy (and thus the actual
> implementation code should be called directly) a typedef should bridge the 2
> with no run time performance penalty.
>
> Darin, Sam, Maciej: does this alleviate your concerns?
>
> Michael, Drew, John: do you think it'd work for workers/appcache as well?


This will work fine for appcache and localstorage, but isn't sufficient for
workers since the same caller gets different objects depending on which
process this is running in.  This doesn't happen for appcache and
localstorage.


>
>
> Everyone: have I completely missed something here?
>
> J
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/493c76ca/attachment.html>