2 ms·

The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated,

The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. In that case, it still needs some explanation. Chrome's process allocator is apparently pretty complicated, so assuming a reader knows enough to just take it as read as "antiquated" is a bit much.

azakai 14y ago
> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.
- stanleydrew 14y ago
  If he actually intended to say that why didn't he just say it? The fact that he leaves us guessing is puzzling.
- bengoodger 14y ago
  I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day. [1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org http://build.chromium.org
  - azakai 14y ago
    > I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
    - georgemcbay 14y ago
      It would be pretty ironic if Apple were actually annoyed that Chrome was developed in secret considering they forked KHTML and developed it into Safari & WebKit in secret in essentially the same way.
    - bengoodger 14y ago
      I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team. I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is. A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app. One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
      - yuhong 14y ago
        Opera is planning to use this, for example.
        cmwelsh 14y ago
        Yes, but only in the sense that Opera is evolving into a new brand of Chromium. Opera isn't a relevant factor in the technology discussion anymore.
comex 14y ago
Another quote is "The mechanism is based on a relatively dated concept, superseded by compile-time code validation techniques such as Google's own Native Client" so I don't think that's what the article meant.

azakai 14y ago

> The actual phrasing is "antiquated style of process isolation", which leads me to believe that he's not saying that process isolation is inherently antiquated, but that the way Chrome does it is. That was my assumption too. Chrome's IPC was developed in secret and never made it into WebKit, instead, Apple later developed WebKit2 - in part as a response to Chrome's IPC - that does IPC for WebKit in a different way. It sounded like the author was saying that Google's way, which is older than WebKit2, is inferior.

stanleydrew 14y ago
If he actually intended to say that why didn't he just say it? The fact that he leaves us guessing is puzzling.
bengoodger 14y ago
I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It's existed publicly for ~4.5 years at http://src.chromium.org/viewvc/chrome/trunk/src/ http://src.chromium.org/viewvc/chrome/trunk/src/ and all of the code is pretty actively developed [1] & [2]. Chromium has now been public much longer than it existed privately, and for any particular file in Chromium, the odds are good that it's substantially different from launch day. [1] http://svnsearch.org/svnsearch/repos/CHROMIUM/search http://svnsearch.org/svnsearch/repos/CHROMIUM/search [2] http://build.chromium.org http://build.chromium.org
- azakai 14y ago
  > I don't see how the fact that Chrome was secret prior to its 9/2/08 launch matters much here. It might not, yeah. But I've heard theories that part of the reason it never made it into WebKit was how it was developed in secret and how that annoyed Apple. Together with v8, another secretly-developed project that also did not replace it's parallel in WebKit.
  - georgemcbay 14y ago
    It would be pretty ironic if Apple were actually annoyed that Chrome was developed in secret considering they forked KHTML and developed it into Safari & WebKit in secret in essentially the same way.
  - bengoodger 14y ago
    I won't speculate on why people make the technology decisions they do - and in this case I'm somewhat distant from the WebKit team. I am pretty familiar with Chrome's multiprocess webview harness. This is one case where approx. 2 years ago it was incestuously tied with a lot of Chrome-the-desktop-browser internals. Part of the technical debt accumulated with the sprint to ship something. So I can see why back then it wasn't appetizing as-is. A heroic effort by a team of engineers finally managed to separate it in 2012 into "content" (not Chrome, get it?) and set up its own shell, suite of tests, and public API for use by embedders (one of which is src/chrome, but there are others now even within Chromium). It's still not as elegant as I think any of us would like, but it is now usable from a standalone app. One of these days I need to write a series of posts about some of the "big C++ app design" lessons we've learned as a team over the past few years.
    - yuhong 14y ago
      Opera is planning to use this, for example.
      - cmwelsh 14y ago
        Yes, but only in the sense that Opera is evolving into a new brand of Chromium. Opera isn't a relevant factor in the technology discussion anymore.

comex 14y ago

Another quote is "The mechanism is based on a relatively dated concept, superseded by compile-time code validation techniques such as Google's own Native Client" so I don't think that's what the article meant.