On Tue, May 26, 2009 at 6:02 PM, Michael Nordman <[email protected]>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"
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
