[webkit-dev] SharedWorkers alternate design
Jeremy Orlow
jorlow at chromium.org
Tue May 26 18:11:18 PDT 2009
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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/43f196dc/attachment.html>
More information about the webkit-dev
mailing list