I think it's a great idea and the only drawback I can see is the WTF
dependency and the security implications, which shouldn't be anything
we couldn't overcome.
The biggest challenges IMHO would be:
1) clearly identifying what backend and frontend mean and where the
separation occurs. I worry (perhaps without substance) that the
definition may vary from port to port.
2) general logistics of actually lopping off huge parts of existing
WebKit code and refactoring them in-flight.
But I totally think we (you) are up to the challenge :)
:DG<
On Tue, Apr 28, 2009 at 5:05 PM, Jeremy Orlow <jor...@chromium.org> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
