The thread (which continues into May) goes over pretty clearly why they felt Pepper was a bad idea.
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.
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.
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.
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.
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.
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.
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.
You gave the example of using canvas from a web worker. Unfortunately, the whole web platform is built on the assumption of a single-threaded execution pipeline. Web workers get around this by using postMessage and not having access to the DOM, shared variables, and other stateful parts of the platform. Canvas and WebGl as spec'd and implemented are tied to these stateful parts of the platform (DOM, etc.), which is why you cannot use them from a worker.
So, your desired change would involve either a major overhaul of the web as spec'd and implemented, or a change to the Canvas and WebGL standards. The first is probably not going to happen. The second is achievable and implementable, but wouldn't help address the use cases I described in my first sentence.
It requires no more engineering effort than it took to implement the corresponding code in the PPAPI, and probably a lot less. Moreover, non-NaCl and non-plugin code could benefit from it.
Maybe I'm really confused because I don't understand.
Here's some further reading:
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.
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.