undefined | Better HN

0 pointssimoncion10y ago0 comments

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.

0 comments

rockdoe10y ago

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.

simoncionOP10y ago

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)

pilif10y ago

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.

1 more reply

kelnos10y ago

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.

j / k navigate · click thread line to collapse