5 ms·

If you read the responses from Chrome engineers on that thread you'll see why a new API was necessary. The requirements and guarantees of your API fundamentally

If you read the responses from Chrome engineers on that thread you'll see why a new API was necessary. The requirements and guarantees of your API fundamentally change when you move it out of process for sandboxing and stability. Naive approaches lead to awful performance, deadlocks, or the need to poke massive holes in your security architecture. After a few engineering years of trying to make NPAPI work, it became clear that the result was so different and banned so much of NPAPI that a clean break was the only correct approach.

ootachi 15y ago
I think the responses from the other browser manufacturers were pretty convincing. The problem, if you read the thread, was not that NPAPI was sufficient. The problem was that Chrome wanted to reinvent all sorts of APIs that already existed in the Web platform. They ignored that issue and did Pepper anyway.
- justinschuh 15y ago
  This is what I meant by "naive approaches." Take your example of Pepper API layer versus NPRuntime. When you try to use a sandboxed NPRuntime plugin you hit a hard performance wall with synchronous dispatch overhead. You also introduce huge potential for deadlocks that can be very difficult to detect. This isn't the kind of thing you notice in a simple simple proof-of-concept or casual discussion, but it becomes painfully obvious when trying to implement a real-world plugin.
  - ootachi 15y ago
    So extend the Web APIs to handle this. You don't have to do synchronous calls. Robert O'Callahan talked in that thread about the potential for extending the capabilities of Web Workers to allow the kind of things you want to do to be done asynchronously. I know I'd love to have the ability to render to a 2D or 3D canvas context in a Web Worker, for example (the kind of thing that sandboxed plugins want to do), but all the effort that could have gone to that went to this weird plugin- (and NaCl-)specific API instead. It's kind of sad, because I would like to use these APIs in my web content, but I can't. The cynic in me would say that it's because Google wants to push NaCl. I don't want to program C++ to get access to these goodies; I want to program in CoffeeScript.
    - drivebyacct2 15y ago
      What are you talking about? Are you suggesting that Adobe provide an implement Flash via Web APIs and Javascript? We're talking about the challenges of having a plugin interface for Chrome and how NPAPI is limited/flawed and you're suggesting... Web APIs? Maybe I'm really confused because I don't understand.
      - ootachi 15y ago
        The proposal that roc and smfr put forth is this: Native code could call Web APIs, slightly tweaked for the benefit of native code and to satisfy the security/isolation guarantees that Chrome wants to enforce. These same APIs would have JavaScript versions, so that ordinary Web content could use them as well. For example, the same asynchronous 3D command stream API that Pepper exposes would be available to Web Workers. Here's some further reading: * https://mail.mozilla.org/pipermail/plugin-futures/2010-May/000095.html https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0... * https://mail.mozilla.org/pipermail/plugin-futures/2010-May/000096.html https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0... Note that Darin's followup message included this: "I do agree however we want to keep Pepper APIs in sync with existing Web APIs. That will obviously be a challenge if they are not one and the same, but I don't think it is impossible or even that difficult to achieve with them being separate APIs." This has already failed. Web Workers cannot render even 2D content asynchronously today, while Pepper can (which advantages plugins and NaCl over ordinary Web content). This is exactly the problem that roc and smfr were trying to avoid. I don't think that Darin's example, of an <embed> tag being untouchable by Web content, is an insurmountable problem. In fact, I think this is exactly the kind of thing you want JavaScript content to be able to do -- high-fidelity JS versions of PDF and Flash would be great. And the issue of Web Workers and audio APIs needing shared memory is a Chrome problem (because Chrome puts each worker in a separate process), but not a problem for browsers generally. Also, the argument that "it's an existing plugin, you don't want them to rewrite their code" doesn't hold water. It's an entirely new set of plugin APIs. Adobe has to rewrite its code anyway. It's just that the other browser vendors wanted the Web as a whole to benefit from this, not just Adobe.
    - justinschuh 15y ago

ootachi 15y ago

I think the responses from the other browser manufacturers were pretty convincing. The problem, if you read the thread, was not that NPAPI was sufficient. The problem was that Chrome wanted to reinvent all sorts of APIs that already existed in the Web platform. They ignored that issue and did Pepper anyway.

justinschuh 15y ago
This is what I meant by "naive approaches." Take your example of Pepper API layer versus NPRuntime. When you try to use a sandboxed NPRuntime plugin you hit a hard performance wall with synchronous dispatch overhead. You also introduce huge potential for deadlocks that can be very difficult to detect. This isn't the kind of thing you notice in a simple simple proof-of-concept or casual discussion, but it becomes painfully obvious when trying to implement a real-world plugin.
- ootachi 15y ago
  So extend the Web APIs to handle this. You don't have to do synchronous calls. Robert O'Callahan talked in that thread about the potential for extending the capabilities of Web Workers to allow the kind of things you want to do to be done asynchronously. I know I'd love to have the ability to render to a 2D or 3D canvas context in a Web Worker, for example (the kind of thing that sandboxed plugins want to do), but all the effort that could have gone to that went to this weird plugin- (and NaCl-)specific API instead. It's kind of sad, because I would like to use these APIs in my web content, but I can't. The cynic in me would say that it's because Google wants to push NaCl. I don't want to program C++ to get access to these goodies; I want to program in CoffeeScript.
  - drivebyacct2 15y ago
    What are you talking about? Are you suggesting that Adobe provide an implement Flash via Web APIs and Javascript? We're talking about the challenges of having a plugin interface for Chrome and how NPAPI is limited/flawed and you're suggesting... Web APIs? Maybe I'm really confused because I don't understand.
    - ootachi 15y ago
      The proposal that roc and smfr put forth is this: Native code could call Web APIs, slightly tweaked for the benefit of native code and to satisfy the security/isolation guarantees that Chrome wants to enforce. These same APIs would have JavaScript versions, so that ordinary Web content could use them as well. For example, the same asynchronous 3D command stream API that Pepper exposes would be available to Web Workers. Here's some further reading: * https://mail.mozilla.org/pipermail/plugin-futures/2010-May/000095.html https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0... * https://mail.mozilla.org/pipermail/plugin-futures/2010-May/000096.html https://mail.mozilla.org/pipermail/plugin-futures/2010-May/0... Note that Darin's followup message included this: "I do agree however we want to keep Pepper APIs in sync with existing Web APIs. That will obviously be a challenge if they are not one and the same, but I don't think it is impossible or even that difficult to achieve with them being separate APIs." This has already failed. Web Workers cannot render even 2D content asynchronously today, while Pepper can (which advantages plugins and NaCl over ordinary Web content). This is exactly the problem that roc and smfr were trying to avoid. I don't think that Darin's example, of an <embed> tag being untouchable by Web content, is an insurmountable problem. In fact, I think this is exactly the kind of thing you want JavaScript content to be able to do -- high-fidelity JS versions of PDF and Flash would be great. And the issue of Web Workers and audio APIs needing shared memory is a Chrome problem (because Chrome puts each worker in a separate process), but not a problem for browsers generally. Also, the argument that "it's an existing plugin, you don't want them to rewrite their code" doesn't hold water. It's an entirely new set of plugin APIs. Adobe has to rewrite its code anyway. It's just that the other browser vendors wanted the Web as a whole to benefit from this, not just Adobe.
  - justinschuh 15y ago