Thoughts on Pepper
brettw at google.com
Fri Apr 30 17:01:45 PDT 2010
On Fri, Apr 30, 2010 at 3:14 PM, Robert O'Callahan <robert at ocallahan.org> wrote:
> (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?
In think this is the best general approach. Taken to the opposite
extreme, we would end up duplicating the entire web platform using
slightly different APIs, which everybody agrees would be worse than
Were planning on using the webby APIs when practical. For example, one
thing we really need for a certain class of plugins is a peer-to-peer
UDP solution. There has been some recent movement to adding such a
thing to HTML, so we're planning on using this as the way for
sandboxed plugins to do UDP. It seems like it would also be nice to
replace the NPAPI network request interface with a streaming
XMLHTTMLRequest-like-thing that there has been some talk of exposing
to JS. I support unifying these whenever possible because I don't want
the extra code or do the extra implementation work, and content
authors don't want to learn two things.
The entirety of things currently in Pepper are:
- 2D painting
- 3D painting
- Find in page
- OS native theming APIs
The things we feel like we need that aren't in there are:
- UDP networking
- Ability to read or write random files after prompting the user
(for file upload and saving)
- Simple sandboxed filesystem for caching files
I don't expect to add much else to "Pepper" proper, so this is really
not that much stuff. There are two classes of things. One is where
Pepper is providing a C-specific or an efficient out-of-process
interface into an API that is otherwise designed for in-process JS.
This makes sense to have the same rules, but a different "frontend"
API for the code to interact with. The second class of things is where
the web platform is currently deficient. I think the long-term goal
should be to add all these capabilities to the web platform. We added
these APIs in pepper mostly because we have a short term need for
them. If they are proven to be useful I think standardizing and
exposing to JS is the right thing.
Let me go through each item:
2D painting: Theoretically we could use a canvas element and the
plugin would paint to that surface using the existing APIs. In the
incomplete demo I'm currently hacking together, I've moved Pepper
painting much closer to the way Canvas works (I hope to send a
description of this out next week sometime assuming it works OK). The
main difference is that we provide a more efficient way to get at the
pixels and the painting model is designed to be asynchronous with a
callback. I'm fine with adding this to the Web API if other vendors
are supportive, but this seems "weird" from the perspective of the JS
model, at least to me.
3D painting: What pepper exposes is OpenGL ES which is the same as the
web platform. The way you execute the functions via a command buffer
rather than specifying individual function calls is slightly different
so we can send the commands more efficiently across process boundaries
rather than doing a context switch for each OpenGL call.
Audio: I don't know enough about this right now to say much.
Find in page: A web interface for this sounds fine to me.
Native theming APIs: We've discussed that some clients may want this
exposed in <canvas> and I don't see any problem with doing that
instead if other vendors agree.
UDP networking: Hopefully when we get around to this it will be unified.
File I/O: There is a HTML spec for something doing file browsing, and
we're using the same backend code in Chrome for Pepper as for the HTML
stuff which we've already started implementing. I've heard talk of a
sandboxed filesystem for caching and such in HTML, although I'm not
familiar with specifics. Clearly location and semantics should be the
The HTML spec for reading & writing files has a very specific
definition for how stuff should be written, for example, using
code. We plan on implementing a Posix-like interface for files. You
would use a special open command that would be provided in Pepper
which would give you a file handle. Then you could use fread() and
iostreams like C and C++ programmers are accustomed to. We believe
this is important for ease-of-use from a C programmer's perspective,
flexibility when dealing with lower-level primitives like you would
typically be doing in C, and for porting existing code which we think
this is a very important part of Pepper.
I see the Pepper file API as just being a lower-level hook into the
existing DOM API that gives you Posix-type control. This is similar to
other systems. If I write a Python program on Linux there is a nice
Python file API I would generally use. If I write a C program, there
is a lower-level Posix one. Both talk to the same filesystem with the
same semantics. The FileWriter stuff is just the JS wrapper on top of
a file handle with certain semantics about permissions and such, and
the Pepper file API would be a Posix API on top of the file handle
with the same semantics.
More information about the plugin-futures