I have always felt like running the WebCore "backend" in the browser process with an IPC channel between it and the frontend was a really elegant design for this problem. And I never really understood why we weren't allowed to depend on WebCore (even indirectly) in the browser process. Is the idea that someday the browser and renderer processes might be separate binaries?
- a On Tue, Apr 28, 2009 at 5:05 PM, Jeremy Orlow <[email protected]> wrote: > Yes, yes, I know this is a "horrible idea", but please hear me out.... :-) > > Last week, a couple of us (Darin F, Michael N, Jeremy M, and I) had lunch at > Apple to talk to talk about sharing more code. HTML 5 brings with it a lot > of APIs that reach outside of the top level browsing context boundary (i.e. > the render process boundary in Chromium). We talked specifically about > localStorage and appCache. Although I believe the following generalizes well > for any such API, I recognize that there are some unique constraints for > stuff like databases...so I'm not even going to talk about them right now. > Anyhow... > For a while now, I've looked at a bunch of ways to make localStorage > multi-process aware, but really none of them have any hope except one: > splitting localStorage into a frontend and backend. The frontend would be > the portion in each renderer process that connects into the JS bindings. A > single backend would store all the data and be shared by the frontends. > Originally, my plan was to do this split and then write my own back end in > the browser process, but there are several problems with this. From a > technical standpoint, it's unclear how testing would work since our > test_shell would be testing a different backend from what's in Chromium. It > also means we have more code to maintain, and that code is completely off of > WebKit's radar. It also makes Apple mad and Dimitri sad. So really, this > doesn't seem like a good solution. > Assuming the only viable solution is having several frontends talking to one > backend (I'm confident this is true) and assuming having our own backend is > not viable (this also seems true), then the only choice is for us to use the > WebCore backend. We can't run this in any renderer process since the > response times for browser->renderer communication are unbounded. So that > leaves either the browser process or some browser helper process. > Creating a helper process for the browser seems like a pretty interesting > idea to me since there's already a lot of somewhat dangerous stuff running > in the browser process. (The only thing I can remember right now is v8 for > parsing .pac files, but I know there's more.) Basically, the helper process > would be a sandboxed process where anything "dangerous" but not bound to a > single renderer process would run. Ideally it would store little to no state > so that the browser could easily restart it and resend any pending messages > if it crashed. For localStorage, the backend (which is part of WebCore) > would run there and all localStorage messages would be proxied through the > browser process. The VFS could be used to retrieve file handles. > The other option is to simply run part of WebCore's localStorage within the > browser process. LocalStorage only depends on WTF, so this really isn't > _that_ terrible of an idea. Thoughts? > Anyhow, the WebKit guys we talked to like the idea of a split > frontend/backend, especially if it means we'll continue sharing code. I > believe Michael is going to be doing something similar for AppCache. > J > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
