[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

I think we're on the same page. What you described sounds good to me.

I think ResourceHandle case is different because its involved in more
than appcache specific stuff. In chrome the calls into the appcache
while resource loading would occur on the chrome-side of the wire from
chrome specific code (not from webcore). In the single-process model,
the calls into the appcache would occur from webcore code.


On Tue, May 26, 2009 at 6:11 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
> On Tue, May 26, 2009 at 6:02 PM, Michael Nordman <michaeln at google.com>
> wrote:
>>
>> > 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?
>>
>> Partly.
>>
>> The split you just described is what I have in mind for the scripting
>> related appcache interfaces. There always exists a hard split between
>> front and back. The nature of the proxy is different depending. Btw, I
>> also have in mind to use webcore's backend appache code in the
>> seperate process (chrome's main process).
>>
>> The appcache is complicated by the fact that in addition to the
>> scripting related interfaces, there are also interfaces around loading
>> resources out of the cache. The loader currently calls into the
>> appcache and wants an answer immediately (syncrhronously). These call
>> happen at times not so friendly to remoting, like in advance of
>> checking the memory cache... so I don't like the idea of injecting
>> sync IPC calls at those times. I'm still wrestling with that part. I
>> have in mind to overload ResourceHandle such that it knows how to load
>> out of the appropiate appcache when needed, but what I haven't worked
>> thru are how this plays well with webcore's memory cache.
>
> Did you say partly because it's more complicated than just splitting one
> class (and only having 1-way sync communication)?  If so, then we're still
> on the same page, because that's what I'll be doing as well.  I was just
> using the StorageBackend as an example, but events will require signals from
> the backend to the frontend, and some abstractions (like StorageArea) make a
> lot of sense whether or not things are split into two pieces, which sounds a
> lot like what you described with ResourceHandle.
>
> If not, what cases are there where you can't cleanly split things into the 2
> buckets: "call the proxy if it exists, otherwise call the implementation"
> and "ALWAYS call the implementation"
>