Thoughts on Pepper

Robert O'Callahan robert at
Fri Apr 30 15:14:13 PDT 2010

(These are my personal thoughts, not any official Mozilla thing.)

I'm assuming that the goal of Pepper is to provide a rich platform API for
sandboxed native code execution across browsers. I think that's a worthwhile

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't; however, we're
working on the latter. See
Pepper offers integration with browser "Find" functionality, but Web apps
like Bespin want that too.)

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...

Are there fundamental reasons to justify creation of a parallel Pepper
platform API?

"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." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the plugin-futures mailing list