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<[email protected]> wrote: > 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
