Pepper is a new Plugin API for browsers proposed by Chrome: https://code.google.com/p/ppapi/

Plugin API is the magic responsible for Java or Flash in your browser. A plugin once installed on your PC may run in a number of browsers, as all use the same API - currently it is NPAPI.

NPAPI (Netscape Plugin API) is very old and Chrome with Pepper wants replace it.

Mozilla doesn't like Pepper, so at least for now Pepper is a Chrome-specific thing: https://wiki.mozilla.org/NPAPI:Pepper

"Mozilla doesn't like Pepper" is a bit of an unfair characterization. A better description would be "only Google likes Pepper", because as far as I am aware Microsoft, Apple and Opera have not expressed any interest in implementing Pepper either. You just see more about Mozilla's thoughts on Pepper because it is a more open organization.

True, and that's why I mentioned only Mozilla - I have no clue what others are saying. Any references to position of Opera, Microsoft and Apple?

Apple very rarely takes positions on technologies that we don't currently support. Here is a past comment conveying a personal opinion from a WebKit engineer though: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

Here's a comment from Maciej (Apple): http://news.ycombinator.com/item?id=2057611

Microsoft never used NSAPI (API that Mozilla, Apple and Opera use) either. They always used ActiveX. After all, the 'N' in 'NSAPI' means 'Netscape'.

Not true. Internet Explorer used to work with both NSAPI and ActiveX plugins, until they pulled support for the former.

"""Netscape-style plug-ins are supported in Internet Explorer 5.5 Service Pack 1 (SP1) and earlier, but are not supported in Internet Explorer 5.5 Service Pack 2 (SP2) and Internet Explorer 6.""" -- http://support.microsoft.com/kb/306790

Thanks, I stand corrected.

I just remember, that there were two versions of Flash - ActiveX for IE and NPAPI for all the others.

Up until IE6, they did; after that, there was an ActiveX control that could load NPAPI plugins.

Apple wants people to write iOS applications. Microsoft wants people to write Windows 8 applications.

It's possible that Mozilla will come around, if Chrome gives them a big enough kick in the pants. Then again, it's equally possible that PNaCL / PPAPI will remain simply an app distribution mechanism for ChromeOS.

But what are the limits? Are there any? What system API does the implementation map to? Epoll on Linux automatically, kqueue on Mac OS X, and whatever on Windows?

There aren't probably any PNaCl specific aspects to these. This is untrusted code so naturally there will be limits.

You could start at http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/api/

Do you know why Mozilla does not seem interested in Pepper?

Both Google and Mozilla wants to obsolete your OS and move general computing in the browser; Google is more pragmatic and sees the need for native code apps on the client side (like games, image processing, etc) so they wants to transform the browser into distribution platform for such apps. Mozilla crew, on the other hand, holds high moral ground and lives in imaginary world where everything can be made with Web technologies, and if something isn't possible right now, we should just wait couple of processor iterations and couple of Web standard iterations.

If companies are people, Google would be someone like Linus, and Mozilla would hang with RMS.

Brendan Eich posted some thoughts on Pepper recently in this comment and many followups:

http://news.ycombinator.com/item?id=4632410

I don't speak for Mozilla, but the position of the non-Google browser vendors in plugin-futures made sense to me: it's simpler to just call the Web APIs from native code. Less code, smaller surface area, fewer APIs for folks to learn.

All I could find. https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

NaCl and JavaScript have the same sandbox rules because they're both foreign code. Extensions have access to some APIs that normal code doesn't, but again those APIs are the same between NaCl and JS.