Thoughts on Pepper

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 > goal. > > 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 > http://hacks.mozilla.org/2010/04/beyond-html5-experiments-with-interactive-audio/. > 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 useless. 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: - Events - 2D painting - 3D painting - Audio - 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 same. The HTML spec for reading & writing files has a very specific definition for how stuff should be written, for example, using FileWriter. This is a good interface for JavaScript, but less so for C 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. Brett