3 ms·

I would really like to see that all NaCl apps have to ship at least a PNaCl binary (and possibly ARM as well). Browsers should verify this and refuse to run app

by quonn 14y ago

I would really like to see that all NaCl apps have to ship at least a PNaCl binary (and possibly ARM as well). Browsers should verify this and refuse to run apps that are x86 only. If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Also it's certainly an improvement over native plugins that not only lack a sandbox, but are also tied to the OS in addition to the CPU. In fact, I suggest that browsers should adopt NaCl at least for plugins, maybe even allowing unrestricted access to the file system, camera, etc. and gradually phase out conventional plugins. Even without the security benefit this still gives us portable plugins.

azakai 14y ago
> If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Even if PNaCl worked today, and even if it gave good performance and portability, it would still not be standardized. The only way to get PNaCl into a new browser would be to use the current implementation (which defines what it is). Having that implementation open source is a good thing. But it isn't as good as JavaScript which has a standard and multiple independent implementations. If you want to write a JS engine in Haskell, for example, you can do that. You can't do that with NaCl or PNaCl, you must use the existing code as is.
- drivebyacct2 14y ago
  So write another new implementation? That's like saying (the first JS engine) is the only one that exists, so every other browser must also use it.
  - azakai 14y ago
    There is a standard for JavaScript, a spec to implement. And new features in the JS language evolve out of a standards process that involves all the browser makers (as well as others). As a result, you can write a new implementation of it, and people do. There is no standard or spec for NaCl, PNaCl or PPAPI. Those things are still being developed, and they change a lot (talk to people that develop for that API to get an idea of how things can change with each 6-week update of Chrome). To implement those, you need to basically "do what Google's implementation does." Trying to track that large and complex - and changing - implementation is practically impossible.

by quonn 14y ago

azakai 14y ago

> If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary). Even if PNaCl worked today, and even if it gave good performance and portability, it would still not be standardized. The only way to get PNaCl into a new browser would be to use the current implementation (which defines what it is). Having that implementation open source is a good thing. But it isn't as good as JavaScript which has a standard and multiple independent implementations. If you want to write a JS engine in Haskell, for example, you can do that. You can't do that with NaCl or PNaCl, you must use the existing code as is.

drivebyacct2 14y ago
So write another new implementation? That's like saying (the first JS engine) is the only one that exists, so every other browser must also use it.
- azakai 14y ago
  There is a standard for JavaScript, a spec to implement. And new features in the JS language evolve out of a standards process that involves all the browser makers (as well as others). As a result, you can write a new implementation of it, and people do. There is no standard or spec for NaCl, PNaCl or PPAPI. Those things are still being developed, and they change a lot (talk to people that develop for that API to get an idea of how things can change with each 6-week update of Chrome). To implement those, you need to basically "do what Google's implementation does." Trying to track that large and complex - and changing - implementation is practically impossible.