Can someone enlighten me about the Pepper API? Could I run a server with it? What would sort of limits does the network connection have? How many requests per second could it handle? How many simultaneous connections? What about bandwidth? etc. etc.
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" 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.
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
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?
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.
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.
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.
I wonder if Apple will selectively sue Samsung because it's a thin, rectangular, silver clamshell with black keys and a screen? (I like the Macbook Air btw)
I'm sure Google's PNaCl ARM solution took this long only because they were waiting to have an easier technical time of it with A15 cores and hardware virtualization. My bet is that they've saved themselves a lot of hassle and gone with implementing a lightweight hypervisor for untrusted native code.
Does anyone know how these work without an active internet connection? Is there an offline / synch option? I think the folks who most need cheap computers are also the ones with the spottiest access...
The announcement is about the new ARM-based Chromebooks, and PNaCl is the way to write performant native apps that run on all architectures supported by Chrome.
Of course, but surely this really cool project that Google has been working on for years and years deserves a bigger announcement than an aside in a netbook preview. Hopefully one will be coming along soon.
PNaCl was announced quite a while ago, and is a publicly developed open source project. The new detail here is just when it should start shipping to stable for use in Apps and Extensions.
