On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak <m...@apple.com> wrote: > On Jan 11, 2013, at 12:21 AM, Adam Barth <aba...@webkit.org> wrote: >>> If you're actually planning to make a significant complexity-imposing >>> architectural change for performance reasons, without any way to test >>> whether it delivers the claimed performance benefits, or how it compares to >>> less complex approaches, then why should any rational person agree with >>> that approach? When attempting to improve performance, the burden of proof >>> is on the person proposing the performance improvement, not on others to >>> create a test to figure out if the performance improvement works. It's not >>> valid to respond to a request for performance testing info with the >>> equivalent of "patches welcome". >> >> Is that really the case? If so, I'm surprised that the patches for >> the shared memory cache and the NetworkProcess landed. I raised >> similar questions to the ones you're raising now, but the folks >> purposing those changes basically ignored me and landed their patches >> anyway. > > NetworkProcess itself exists primarily for correctness reasons in the face of > process-per-tab. I hope the idea of handling networking outside any of the > web/render processes in a process-per-tab architecture is not itself > controversial.
I don't want delve too deeply into this issue because it's primarily a WebKit2 concern. However, I'll note that in Chromium, networking is just a thread in the UIProcess rather than a separate process. I haven't really thought though the consequences of that design choice. My point is more that folks just started landing patches for the NetworkProcess without discussing the design with the community. That's fine if you're not interested feedback from the community, but I've also heard repeated requests to share more code between Chromium and WebKit2. If you don't seek feedback on your designs, it's unlikely that you'll happen to design something that Chromium will be able to adopt in the future. Put another way, I don't think it's reasonable to simultaneously design WebKit2 without community feedback and also to complain when Chromium doesn't adopt WebKit2 (in part or in whole). > What I know is controversial, and I believe merits further follow-up > discussion, is the choice of where proxying of networking to an outside > process should hook in - whether at the ResourceHandle layer (as Chromium > does it), or at the CachedResource layer, as WebKit2 is doing it. That choice > involves hypotheses about both performance and appropriate architecture. I > feel that the WebKit2 folks have not provided sufficient public data to fully > justify the choice of where to hook things in, and I will encourage things to > do so. On the other hand, Chromium folks historically did not really provide > a lot of data or justification for why the ResourceHandle was the right > place. Rather, it was presented as a "constraint" and a must-have for merging > back to the WebKit repository. To me, that's seems like a pretty revisionist version of history. At the time Chromium landed, it wasn't at all practical to hook in at the cached resource layer because many (most?) loading codepaths bypassed the memory cache. It's only because of Nat's work to unify the loader code paths that it's even possible today. As Brady found, it wasn't even possible when he started out because main resources didn't flow through the memory cache until this past month. > Long term, it is obviously somewhat regrettable if we end up diverging on > this point, and therefore having two different insertion points for proxying, > as that makes WebKit overall more complex. Agreed. > I think your whitepaper on the topic was a good start on outlining some of > the pros and cons. I commented on it a bit in email and via the comment > system, but discussion died down (probably due to vacations and then the > holidays). > > Here it is for reference of others: > <https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit?pli=1> > > In addition to my previous comments, I believe some topic not yet fully > covered by your whitepaper are: > - Hooking in proxying at the ResourceHandle layer may require threading > information through ResourceHandle that it logically should not need to know > (if one thinks of it as a an abstraction on top of a low-level networking > API), such as association with a specific frame/page, or > - How to connect loading mechanisms that bypass ResourceHandle or otherwise > bypass the network stack (e.g. Application Cache, WebArchives, blob: URLs > (currently implemented as a magic ResourceHandle subclass), etc. The two > approaches have different architectural implications for this type of > feature. I am not sure offhand which approach is cleaner or whether one way > or the other has more pragmatic benefits. > > I'll add also that it seems possible in principle to make all WebCore loading > go through the CachedResource layer, jut as it's possible to have it all go > through the ResourceHandle layer, and it's likely beneficial to do so though > the benefits in cases of more marginal load types may be small. The main point I was trying to make in the document is that hooking in at the CachedResource layer has worse security properties than hooking in at the ResourceHandle layer. I understand that Safari and Chromium have different goals when it comes to security, which I believe is the main reason you're even willing to consider hooking in at the CachedResource layer. In particular, Chromium needs to be able to run in a strong sandbox on Windows XP. Unlike Mac OS X, Windows XP does not have a particularly sensible sandboxing mechanism, mostly because the OS mechanisms that we use in Chromium were not intended to be used for sandboxing by the designers of XP. As a consequence, any network requests that we fail to hook will simply fail (or more likely just crash). For that reason, we need complete interposition, which means we need to hook into WebCore at a layer like ResourceHandle that has actually has complete interposition. Moreover, we've enjoyed the security benefits of complete interposition for a while now and have raised our security goals, namely we're interested in achieving software fault isolation based API integrity. As far as I can tell, the approach WebKit2 has taken to out-of-proces networking is not compatible with software fault isolation based API integrity. Now, I understand if that sounds very futuristic to you given the current security posture of the apple-mac port, but if you're serious about working on a common design, you need to be willing to accept design goals and constraints beyond those that affect the apple-mac port. As long as you minimize or ignore those constraints, it's unlikely that the folks who have those goals and constraints will be interested in adopting your designs. Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
