[webkit-dev] SharedWorkers alternate design

[Michael Nordman]

> 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.