5 ms·

This is always Mozilla's excuse. It's not as if Google hasn't published their source code or their documentation: https://developer.chrome.com/native-client/c-

This is always Mozilla's excuse. It's not as if Google hasn't published their source code or their documentation: https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api It's not as if Google isn't willing to work with other browser vendors to translate this into a formal spec. It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. How is that any different than PPAPI?

pcwalton 11y ago
Please read the mailing list thread I linked. It isn't a long thread. The problem is not just that PPAPI is unspecified, although that is a problem. The problem is that the consensus is/was that PPAPI is the wrong approach entirely, because we already have the Web APIs. Inventing parallel APIs instead of providing a way for native code to call Web APIs just adds a lot of complexity to the platform for no reason. > It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. Nobody's happy with NPAPI. That's why it's being dropped. "Just as good as NPAPI" is not the bar we want to meet in 2015.
- teacup50 11y ago
  What made NPAPI something nobody is happy with has little to do with standardization approaches. Web APIs aren't a replacement for a plugin mechanism, and never will be, because they live below the browser instead of as a peer of the browser. Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser.
  - pcwalton 11y ago
    > Web APIs aren't a replacement for a plugin mechanism, and never will be, because they live below the browser instead of as a peer of the browser. NPAPI is mostly below the browser nowadays. And PPAPI is completely "below the browser". In fact, that's its entire reason for existing. > Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser. I would love to implement more and more of the Web platform using the Web APIs, and there has been continuous motion in that direction for a long time.
    - teacup50 11y ago
      Continuous motion, maybe. Continuous forward motion, not so much.

pcwalton 11y ago

Please read the mailing list thread I linked. It isn't a long thread. The problem is not just that PPAPI is unspecified, although that is a problem. The problem is that the consensus is/was that PPAPI is the wrong approach entirely, because we already have the Web APIs. Inventing parallel APIs instead of providing a way for native code to call Web APIs just adds a lot of complexity to the platform for no reason. > It's not as if you even need to have a formal spec for the plugin API! The previous standard, "NPAPI", is the Netscape Plugin API, which was informally specified for Netscape, and then adopted by other browser vendors. Nobody's happy with NPAPI. That's why it's being dropped. "Just as good as NPAPI" is not the bar we want to meet in 2015.

teacup50 11y ago
What made NPAPI something nobody is happy with has little to do with standardization approaches. Web APIs aren't a replacement for a plugin mechanism, and never will be, because they live below the browser instead of as a peer of the browser. Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser.
- pcwalton 11y ago
  > Web APIs aren't a replacement for a plugin mechanism, and never will be, because they live below the browser instead of as a peer of the browser. NPAPI is mostly below the browser nowadays. And PPAPI is completely "below the browser". In fact, that's its entire reason for existing. > Your dedication to a two-tier system of platform-level code access would be less hypocritical if you imposed the same restrictions on yourself -- but of course, if you did that, you couldn't actually ship a working, high-performing browser. I would love to implement more and more of the Web platform using the Web APIs, and there has been continuous motion in that direction for a long time.
  - teacup50 11y ago
    Continuous motion, maybe. Continuous forward motion, not so much.