> 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. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
