7 ms·

For reference, here are the thoughts of Robert O'Callahan from Mozilla (and those of Simon Fraser from Apple) on Pepper: https://mail.mozilla.org/pipermail/plug

by ootachi 15y ago

For reference, here are the thoughts of Robert O'Callahan from Mozilla (and those of Simon Fraser from Apple) on Pepper: https://mail.mozilla.org/pipermail/plugin-futures/2010-April/000088.html https://mail.mozilla.org/pipermail/plugin-futures/2010-April... The thread (which continues into May) goes over pretty clearly why they felt Pepper was a bad idea.

MatthewPhillips 15y ago
Google has a nasty habit of developing some technology in a dark room, then dropping it on the web community and being confused when no one is that interested (Dart is the other big example). It makes me wonder if they really want these projects to be cross-platform successful or not.
- shimon_e 15y ago
  Adobe is dropping linux support after 11.2. With the except of Chrome due to a new API that "aims to provide a layer between the plugin and browser that abstracts away differences between browser and operating system implementations." Given that linux really hasn't been a priority for them and they are dropping flash all together; this isn't really news. The press release says Adobe worked with Google on Pepper. So for them to have a bias towards it isn't groundbreaking.
  - gcp 15y ago
    With the except of Chrome due to a new API This is what's hard to understand: they are not dropping NPAPI on Windows, so it's not like the Chrome API is the enabler here.
    - jaredsohn 15y ago
      My assumption is that among {NPAPI/Windows, NPAPI/Linux, PPAPI/Windows, PPAPI/Linux}, NPAPI/Linux provides the least value for the work required.
      - shimon_e 15y ago
        Its more like among {NPAPI/Firefox/Windows, NPAPI/Firefox/Linux, NPAPI/IE/Windows, PPAPI/ALL, etc}, NPAPI/Firefox/Linux provides the least value.
        bzbarsky 15y ago
        There is no NPAPI/IE/Windows, for what it's worth. It's ActiveX/IE/Windows.
    - shimon_e 15y ago
      From the press release it seems NPAPI is OS dependent while Pepper is less so. This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
      - jaredsohn 15y ago
        >This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux. There will be updates and they will be desirable in Linux assuming people continue creating Flash content that makes use of the new features: http://news.ycombinator.com/item?id=3621096 http://news.ycombinator.com/item?id=3621096.
        shimon_e 15y ago
        Interesting. So there will be another 3 version with the following features: Keyboard input support in full-screen mode Improved audio support for working with low-latency audio Ability to progressively stream textures for Stage 3D content LZMA compression support for ByteArray Frame label events ActionScript workers (enables concurrent ActionScript execution on separate threads) Support for advanced profiling Support for more hardware-accelerated video cards (from 2005/2006) in order to expand availability of hardware accelerated content Improved ActionScript performance when targeting Apple iOS (What the??? iOS???) Performance index API to inform about performance capabilities of current environment Release outside mouse event API Refactoring and modernizing the current core Flash runtime code base Work on the ActionScript Virtual Machine Updates to the ActionScript language -- Doesn't seem like there will be anything new that can not be currently albeit less efficiently.
      - justinschuh 15y ago
        >From the press release it seems NPAPI is OS dependent while Pepper is less so. Correct. The NPAPI version of Flash is very platform-dependent; whereas Pepper Flash is almost completely platform neutral, and Chrome OS needs most of the same Pepper platform bits anyway. So, our maintenance overhead for Pepper Flash on Linux is very small. On top of that, Linux is broadly deployed throughout Google (and is very popular among Chrome developers), so we're scratching our own itch a bit.
justinschuh 15y ago
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.

by ootachi 15y ago

MatthewPhillips 15y ago

Google has a nasty habit of developing some technology in a dark room, then dropping it on the web community and being confused when no one is that interested (Dart is the other big example). It makes me wonder if they really want these projects to be cross-platform successful or not.

shimon_e 15y ago
Adobe is dropping linux support after 11.2. With the except of Chrome due to a new API that "aims to provide a layer between the plugin and browser that abstracts away differences between browser and operating system implementations." Given that linux really hasn't been a priority for them and they are dropping flash all together; this isn't really news. The press release says Adobe worked with Google on Pepper. So for them to have a bias towards it isn't groundbreaking.
- gcp 15y ago
  With the except of Chrome due to a new API This is what's hard to understand: they are not dropping NPAPI on Windows, so it's not like the Chrome API is the enabler here.
  - jaredsohn 15y ago
    My assumption is that among {NPAPI/Windows, NPAPI/Linux, PPAPI/Windows, PPAPI/Linux}, NPAPI/Linux provides the least value for the work required.
    - shimon_e 15y ago
      Its more like among {NPAPI/Firefox/Windows, NPAPI/Firefox/Linux, NPAPI/IE/Windows, PPAPI/ALL, etc}, NPAPI/Firefox/Linux provides the least value.
      - bzbarsky 15y ago
        There is no NPAPI/IE/Windows, for what it's worth. It's ActiveX/IE/Windows.
  - shimon_e 15y ago
    From the press release it seems NPAPI is OS dependent while Pepper is less so. This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux.
    - jaredsohn 15y ago
      >This all assume there is actually going to be something more than security updates after 11.2 for other platforms. And that it is going to be something we would want on Linux. There will be updates and they will be desirable in Linux assuming people continue creating Flash content that makes use of the new features: http://news.ycombinator.com/item?id=3621096 http://news.ycombinator.com/item?id=3621096.
      - shimon_e 15y ago
        Interesting. So there will be another 3 version with the following features: Keyboard input support in full-screen mode Improved audio support for working with low-latency audio Ability to progressively stream textures for Stage 3D content LZMA compression support for ByteArray Frame label events ActionScript workers (enables concurrent ActionScript execution on separate threads) Support for advanced profiling Support for more hardware-accelerated video cards (from 2005/2006) in order to expand availability of hardware accelerated content Improved ActionScript performance when targeting Apple iOS (What the??? iOS???) Performance index API to inform about performance capabilities of current environment Release outside mouse event API Refactoring and modernizing the current core Flash runtime code base Work on the ActionScript Virtual Machine Updates to the ActionScript language -- Doesn't seem like there will be anything new that can not be currently albeit less efficiently.
    - justinschuh 15y ago
      >From the press release it seems NPAPI is OS dependent while Pepper is less so. Correct. The NPAPI version of Flash is very platform-dependent; whereas Pepper Flash is almost completely platform neutral, and Chrome OS needs most of the same Pepper platform bits anyway. So, our maintenance overhead for Pepper Flash on Linux is very small. On top of that, Linux is broadly deployed throughout Google (and is very popular among Chrome developers), so we're scratching our own itch a bit.

justinschuh 15y ago

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.