[simoncion]

I've gotta raise an eyebrow on that one. If it's a major rewrite to support a new plugin authoring language, your plugin architecture was a terrible mess to begin with.

Given that we're supposed to believe that New Internet Explorer was pretty much a from-the-ground-up rewrite, I can't imagine that their plugin architecture is a terrible mess.

[rockdoe]

NaCl isn't simply a plugin architecture. It is effectively the entire Chrome sandbox and large parts of Chrome architecture made available to binary plugins.

You aren't pulling it into your project without also pulling in half of Chrome.

[simoncion]

According to this [0], NaCl is a Pepper plugin. [1] This would strongly imply that all you'd need to do to use NaCl is to implement PPAPI. Care to point out how I'm wrong about that?

[0] https://www.chromium.org/nativeclient/getting-started/gettin...

[1] Indeed, in a vaguely-recent Chrome, about:plugins has this to say about NaCl:

Native Client

Name: Native Client

Version:

Location: /opt/google/chrome/internal-nacl-plugin

Type: PPAPI (in-process)

[pilif]

the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need.

Check https://developer.chrome.com/native-client/c-api for a list of currently supported features.

For other browsers to support PPAPI, they'd have to implement all of this, which, btw, also is a moving target that moves forward in lockstep with chrome releases.

[mortehu]

> the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement

I've looked at the API, and can't agree with your statement. The API is similar to a typical game engine API. There are classes for handling input devices, audio, OpenGL, hardware video decoding, filesystem access, and basic networking. The PPAPI does not even touch the DOM, so it's not tied to being in a web browser.

[pcwalton]

It's also not spec'd; there are many edge cases in the implementation that are undocumented and would have to be specified precisely in order to be implementable by others. Nobody has done that work so far.

Here's a random example bz pointed out from a few years ago: https://news.ycombinator.com/item?id=5452098

[pilif]

By "tied to chrome's inner workings" I meant the implementation itself which can't be lifted off of Chrome because of that. So PPAPI would need to be re-implemented by other browsers which is difficult as it's very much a moving target without an official standards process.

Basically what happens is that their flash plugin or some internal chrome app needs feature X at which point they extend PPAPI to have feature X. Trying to play catch-up with this kind of development is frustrating and difficult.

And aside of that, browser vendors don't like the fact that PPAPI is more or less re-implementing other existing web technologies. Here's a writeup by Robert O'Callahan from 2010 that goes into this reasoning: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

[strcat]

PPAPI is just providing an alternate, lower-level interface to the same web techniques accessible via JavaScript APIs. There's a bit more power (OpenGL ES 2.0, not the crippled WebGL standard based upon it) but nothing very significant. It's not browser-specific but it's also not going beyond what browsers provide.

[anonbanker]

I laughed real hard at the "just" in your sentence. thank you for that.

[kelnos]

NPAPI (the old plugin architecture) is a terrible mess. It's 20 years old as of this year, and was cobbled together by Netscape back for version 2.0.