5 ms·

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have d

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run with, Apple created its own framework. That had advantages and disadvantages. More generally, I'd point to the Content layer as a better integration point: Opera, for instance, is building on top of our multi-process architecture successfully. Chromium Embedded Framework (https://code.google.com/p/chromiumembedded/ https://code.google.com/p/chromiumembedded/) is another example of how other projects can leverage the work we've done.

macrael 13y ago
A stunningly reductive question deserves to be responded to in kind :) I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?
- mikewest 13y ago
  Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair. The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits. Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&v=5 http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)
othermaciej 13y ago
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no. At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.) Writing our own seemed like the least bad approach. If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently. I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).
- Me1000 13y ago
  I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.
  - itafroma 13y ago
    A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split. Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.
  - deleted 13y ago
    [deleted]

macrael 13y ago

A stunningly reductive question deserves to be responded to in kind :) I don't know much of this history, but was integrating Chrome's processor model into WebKit feasible at the time that WebKit2 was built? What were the reasons for not doing so?

mikewest 13y ago
Generally, I think WebKit2 and Chromium simply disagree about where to hook into the platform, and what the responsibilities of the embedder should be. The description at http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 is written from Apple's point of view, but I think it's broadly fair. The position we're taking is that the Content layer (in Chromium) is the right place to hook into the system: http://www.chromium.org/developers/content-module http://www.chromium.org/developers/content-module That's where we've drawn the boundary between the embeddable bits and the Chrome and browser-specific bits. Regarding the history, I'd suggest adding some questions to the Moderator for tomorrow's video Q/A: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&v=5 http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38... The folks answering questions there were around right at the beginning... I only hopped on board ~2.5 years ago. :)

othermaciej 13y ago

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no. At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.) Writing our own seemed like the least bad approach. If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently. I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).

Me1000 13y ago
I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.
- itafroma 13y ago
  A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split. Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.
- deleted 13y ago
  [deleted]