(These are my personal thoughts, not any official Mozilla thing.)<br><br>I&#39;m assuming that the goal of Pepper is to provide a rich platform API for sandboxed native code execution across browsers. I think that&#39;s a worthwhile goal.<br>
<br>But browsers already offer a rich platform API to sandboxed code: the standards-based Web APIs. Currently Pepper offers some functionality that Web APIs do not, but I see no reason why native code will ultimately want different functionality from JS Web apps. (For example, Pepper offers sample-level sound playback and current Web APIs don&#39;t; however, we&#39;re working on the latter. See <a href="http://hacks.mozilla.org/2010/04/beyond-html5-experiments-with-interactive-audio/">http://hacks.mozilla.org/2010/04/beyond-html5-experiments-with-interactive-audio/</a>. Pepper offers integration with browser &quot;Find&quot; functionality, but Web apps like Bespin want that too.)<br>
<br>Therefore it seems a duplication of effort to specify, implement and evangelize a parallel set of platform APIs for native code, if native code can just use Web APIs. This is already possible with NPAPI using NPRuntime, although a lot could be done to improve the convenience and performance of native code bindings to WebIDL. Or imagine an alternative approach to NPAPI where we have new Web API to import a blob of sandboxed native code and make calls into and out of it. The blob could create a WebGL canvas, add some DOM event handlers to it, and away we go...<br>
<br>Are there fundamental reasons to justify creation of a parallel Pepper platform API?<br><br>Rob<br>-- <br>&quot;He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all.&quot; [Isaiah 53:5-6]<br>